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Abstract. Single sign-on (SSO) systems, such as OpenID and OAuth, allow web sites, so-called relying parties 
(RPs), to delegate user authentication to identity providers (IdPs), such as Facebook or Google. These systems are 
very popular, as they provide a convenient means for users to log in at RPs and move much of the burden of user 
authentication from RPs to IdPs. 

There is. however, a downside to current systems, as they do not respect users' privacy: IdPs learn at which RP a user 
logs in. With one exception, namely Mozilla’s BrowsetTD system (a.k.a. Mozilla Persona), current SSO systems 
were not even designed with user privacy in mind. Unfortunately, recently discovered attacks, which exploit design 
flaws of BrowserlD, show that BrowserlD does not provide user privacy either. 

In this paper, we therefore propose the first privacy-respecting SSO system for the web, called SPRESSO (for Secure 
Privacy-REspecting Single Sign-On). The system is easy to use, decentralized, and platform independent. It is based 
solely on standard HTML5 and web features and uses no browser extensions, plug-ins, or other executables. 
Existing SSO systems and the numerous attacks on such systems illustrate that the design of secure SSO systems is 
highly non-trivial. We therefore also cany out a formal analysis of SPRESSO based on an expressive model of the 
web in order to formally prove that SPRESSO enjoys strong authentication and privacy properties. 
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1 Introduction 


Web-based Single Sign-On (SSO) systems allow a user to identify herself to a so-called relying party (RP), which 
provides some service, using an identity that is managed by an identity provider (IdP), such as Facebook or Google. 
If an RP uses an SSO system, a user does not need a password to log in at the RP Instead, she is authenticated by the 
IdP, which exchanges some data with the RP so that the RP is convinced of the user’s identity. When logged in at the 
IdP already, a user can even log in at the RP by one click without providing any password. This makes SSO systems 
very attractive for users. These systems are also very convenient for RPs as much of the burden of user authentication, 
including, for example, the handling of user passwords and lost passwords, is shifted to the IdPs. This is why SSO 
systems are very popular and widely used on the web. Over the last years, many different SSO systems have been 
developed, with OpenID [13] (used by Google, Yahoo, AOL, and Wordpress, for example) and OAuth [14] (used by 
Twitter, Facebook, PayPal, Microsoft, GitHub, and Linkedln, for example) being the most prominent of such systems; 
other SSO systems include SAML/Shibboleth, CAS, and WebAuth. 

There is, however, a downside to these systems: with one exception, none of the existing SSO systems have been 
designed to respect users’ privacy. That is, the IdP always knows at which RP the user logs in, and hence, which 
services the user uses. In fact, exchanging user data between IdPs and RPs directly in every login process is a key part 
of the protocols in OpenID and OAuth, for example, and thus, IdPs can easily track users. 

The first system so far which was designed with the intent to respect users’ privacy was the BrowserlD system 
[19,20], which is a relatively new system developed by Mozilla and is also known by its marketing name Persona. 

Unfortunately, in [12] severe attacks against BrowserlD were discovered, which show that the privacy of BrowserlD 
is completely broken: these attacks allow malicious IdPs and in some versions of the attacks even arbitrary parties 
to check the login status of users at any RP with little effort (see Section 2.1 for some more details on these attacks). 
Even worse, these attacks exploit design flaws of BrowserlD that, as discussed in [12], cannot be fixed without a major 
redesign of the system, and essentially require building a new system. As further discussed in Section 2.4, besides the 
lack of privacy there are also other issues that motivate the design of a new system. 

The goal of this work is therefore to design the (first) SSO system which respects users’ privacy in the sense 
described above, i.e., IdPs (even completely malicious ones) should not be able to track at which RPs users log 
in. Moreover, the history of SSO systems shows that it is highly non-trivial to design secure SSO systems, not only 
w.r.t. privacy requirements, but even w.r.t. authentication requirements. Attacks easily go unnoticed and in fact numerous 
attacks on SSO systems, including attacks on OAuth, OpenID, Google ID, Facebook Connect, SAML, and BrowserlD 
have been uncovered which compromise the security of many services and users at once [4-6,21,22,25-28], Besides 
designing and implementing a privacy-respecting SSO system, we therefore also carry out a formal security analysis 
of the system based on an expressive model of the web infrastructure in order to provide formal security guarantees. 
More specifically, the contributions of our work are as follows. 

Contributions of this Paper. In this work, we propose the system SPRESSO (for Secure Privacy-REspecting Single 
Sign-On). This is the first SSO system which respects user’s privacy. The system allows users to log in to RPs with 
their email addresses. A user is authenticated to an RP by the IdP hosting the user’s email address. This is done in such 
a way that the IdP does not learn at which RP the user wants to log in. 

Besides strong authentication and privacy guarantees (see also below), SPRESSO is designed in such a way that it 
can be used across browsers, platforms, and devices. For this purpose, SPRESSO is based solely on standard HTML5 
and web features and uses no browser extensions, plug-ins, or browser-independent executables. 

Moreover, as further discussed in Section 2.1, SPRESSO is designed as an open and decentralized system. For 
example, in contrast to OAuth, SPRESSO does not require any prior coordination or setup between RPs and IdPs: users 
can log in at any RP with any email address with SPRESSO support. 

We formally prove that SPRESSO enjoys strong authentication and privacy properties. Our analysis is based 
on an expressive Dolev-Yao style model of the web infrastructure [10]. This web model is designed independently 
of a specific web application and closely mimics published (de-facto) standards and specifications for the web, for 
instance, the HTTP/1.1 and HTML5 standards and associated (proposed) standards. It is the most comprehensive web 
model to date. Among others, HTTP(S) requests and responses, including several headers, such as cookie, location, 
strict transport security (STS), and origin headers, are modeled. The model of web browsers captures the concepts of 
windows, documents, and iframes, including the complex navigation rules, as well as new technologies, such as web 
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storage and cross-document messaging (postMessages). JavaScript is modeled in an abstract way by so-called scripting 
processes which can be sent around and, among others, can create iframes and initiate XMLHTTPRequests (XHRs). 
Browsers may be corrupted dynamically by the adversary. 

So far, this web model has been employed to analyze trace-based properties only, namely, authentication properties. 
In this work, we formulate, for the first time, strong indistinguishability/privacy properties for web applications. Our 
general definition is not tailored to a specific web application, and hence, should be useful beyond our analysis of 
SPRESSO. These properties require that an adversary should not be able to distinguish two given systems. In order to 
formulate these properties we slightly modify and extend the web model. 

Finally, we formalize SPRESSO in the web model and formally state and prove strong authentication and privacy 
properties for SPRESSO. The authentication properties we prove are central to any SSO system, where our formulation 
of these properties follows the one in [10]. As for the privacy property, we prove that a malicious IdP cannot distinguish 
whether an honest user logs in at one RP or another. The analysis we carry out in this work is also interesting by itself, 
as web applications have rarely been analyzed based on an expressive web model (see Section 8). 

Structure of this Paper. In Section 2, we describe our system and discuss and motivate design choices. We then, in 
Section 3, briefly recall the general web model from [10] and explain the modifications and extensions we made. The 
mentioned strong but general definition of indistinguishability/privacy for web applications is presented in Section 4. In 
Section 5, we provide the formal model of SPRESSO, based on which we state and analyze privacy and authentication 
of SPRESSO in Sections 6 and 7, respectively. Further related work is discussed in Section 8. We conclude in Section 9. 
All details and proofs are available in the appendix. An online demo and the source code of SPRESSO are available 
at [23]. 

2 Description of SPRESSO 

In this section, we first briefly describe the main features of SPRESSO. We then provide a detailed description of the 
system in Section 2.2, with further implementation details given in Section 2.3. To provide additional intuition and 
motivation for the design of SPRESSO, in Section 2.4 we discuss potential attacks against SPRESSO and why they are 
prevented. 

2.1 Main Features 

SPRESSO enjoys the following key features: 

Strong Authentication and Privacy. SPRESSO is designed to satisfy strong authentication and privacy properties. 

Authentication is the most fundamental security property of an SSO system. That is, i) an adversary should not 
be able to log in to an RP, and hence, use the service of the RP, as an honest user, and ii) an adversary should not be 
able to log in the browser of an honest user under an adversary’s identity (identity injection). Depending on the service 
provided by the RP, a violation of ii) could allow the adversary to track an honest user or to obtain user secrets. We note 
that in the past, attacks on authentication have been found in almost all deployed SSO systems (e.g., OAuth, OpenID, 
and BrowserlD [10, 12,22,24,25,27, 28]). 

While authentication assumes the involved RP and IdP to be honest, privacy is concerned with malicious IdPs. 
This property requires that (malicious) IdPs should not be able to track at which RPs specific users log in. As already 
mentioned in the introduction, so far, except for BrowserlD, no other SSO system was designed to provide privacy. 
(In fact, exchanging user data between IdPs and RPs directly is a key part of the protocols in OpenID and OAuth, for 
example, and hence, in such protocols, IdPs can easily track at which RP a user logs in.) However, BrowserlD failed 
to provide privacy: As shown in [12], a subtle attack allowed IdPs (and in some versions of the attack even arbitrary 
parties) to check the login status of users at any RP. More specifically, by running a malicious JavaScript within the 
user’s browser, an IdP can, for any RP, check whether the user is logged in at that RP by triggering the (automatic) 
login process and testing whether a certain iframe is created during this process or not. The (non-)existence of this 
iframe immediately reveals the user’s login status. Hence, a malicious IdP can track at which RP a user is logged in. As 
we discuss in [12], this could not be fixed without a major redesign of BrowserlD. Our work could be considered such 
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HTTPS messages, — ► XHRs (over HTTPS), - -> postMessages, browser commands 

Fig. 1 . SPRESSO Login Flow. 


6 






































































a major redesign. While SPRESSO shares some basic concepts with BrowserlD, SPRESSO is, however, not based on 
BrowserlD, but a new system built from scratch (see the discussion in Section 2.4). 

The above shows that the design of a secure SSO system is non-trivial and that attacks are very easy to overlook. 
As already mentioned in the introduction, we therefore not only designed and implemented SPRESSO to meet strong 
authentication and privacy properties, but also perform a formal analysis of SPRESSO in an expressive model of the 
web infrastructure in order to show that SPRESSO in fact meets these properties. 

An Open and Decentralized System. We created SPRESSO as a decentralized, open system. In SPRESSO, users are 
identified by their email addresses, and email providers certify the users’ authenticity. Compared to OpenID, users do 
not need to learn a new, complicated identifier — an approach similar to that of BrowserlD. But unlike in BrowserlD, 
there is no central authority in SPRESSO (see also the discussion in Section 2.4). In contrast to OAuth, SPRESSO 
does not require any prior coordination or setup between RPs and IdPs: Users can log in at any RP with any email 
address with SPRESSO support. For email addresses lacking SPRESSO support, a seamless fallback can be provided, 
as discussed later. 

Adherence to Web Standards. SPRESSO is based solely on standard HTML5 and web features and uses no browser 
extensions, plug-ins, or other client-side executables. This guarantees that SPRESSO can be used across browsers, 
platforms and devices, including both desktop computers and mobile platforms, without installing any software (besides 
a browser). Note that on smartphones, for example, browsers usually do no support extensions or plug-ins. 


2.2 Login Flow 

We now explain SPRESSO by a typical login flow in the system. SPRESSO knows three distinct types of parties: 
relying parties (RPs), i.e., web sites where a user wishes to log in, identity providers (IdPs), providing to RPs a proof 
that the user owns an email address (identity), and forwarders (FWDs), who forward messages from IdPs to RPs within 
the browser. We start with a brief overview of the login flow and then present the flow in detail. 

Overview. On a high level, the login flow consists of the following steps: First, on the RP web site, the user enters 
her email address. RP then creates what we call a tag by encrypting its own domain name and a nonce with a freshly 
generated symmetric key. This tag along with the user’s email address is then forwarded to the IdP. Due to the privacy 
requirement, this is done via the user’s browser in such a way that the IdP does not learn from which RP this data was 
received. Note also that the tag contains RP’s domain in encrypted form only. The IdP then signs the tag and the user’s 
email address (provided that the user is logged in at the IdP, otherwise the user first has to log in). This signature is 
called the identity assertion (IA). The IA is then transferred to the RP (again via the user’s browser), which checks the 
signature and consistency of the data signed and then considers the user with the given email address to be logged in. 
We note that passing the IA to the RP is done using an FWD (the RP determines which one is used) as it is important 
that the IA is delivered to the correct RP (RP document). The IdP cannot ensure this, because, again due to the privacy 
requirements, IdP is not supposed to know the intended RP. 

Detailed Flow. We now take a detailed look at the SPRESSO login flow. We refer to the steps of the protocol as depicted 
in Figure 1. We use the names RP, IdP, and FWD for the servers of the respective parties. We use RPdoc, RPRedirDoc, 
IdPdoc, and FWDdoc as names for HTML documents delivered by the respective parties. The login flow involves the 
servers RP, IdP, and FWD as well as the user’s browser (gray background), in which different windows/iframes are 
created: first, the window containing RPdoc (which is present from the beginning), second, the login dialog created 
by RPdoc (initially containing RPRedirDoc and later IdPdoc), and third, an iframe inside the login dialog where the 
document FWDdoc from FWD is loaded. 

As the first step in the protocol, the user opens the login page at RP [JJ The actual login then starts when the user 
enters her email address Ig], RPdoc sends this address in a POST request to RP HJ. RP identifies the IdP (from the 
domain in the email address) and retrieves a support document from IdP [H This document is retrieved from a fixed 
URL https: //IdPdomain/. well-known/spresso- inf o and contains a public (signature verification) key of the 
IdP. RP now selects new nonces/symmetric keys rpNonce , iaKey, tagKey , and loginSessionToken ^ and creates the tag 
tag by encrypting RP’s domain RPDomain and the nonce rpNonce under tagKey [s]. Using standard Dolev-Yao notation 
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(see also Section 3), we denote this term by 

tag := enc s ((RPDomain, rpNonce ), tagKey). 

RP further selects an FWD (e.g., a fixed one from its settings). Now, RP stores tag, iaKey, the FWD domain, and the 
email address in its session data store under the session key loginSessionToken and sends tagKey, FWDDomain, and 
loginSessionToken as response to the POST request by RPdoc T. 

RPdoc now opens the login dialog. Ultimately, this window contains the login dialog from IdP (IdPdoc) so that 
the user can log in to IdP (if not logged in already). However, to preserve the user’s privacy (see the discussion in 
Section 2.4), RPdoc does not launch the dialog with the URL of IdPdoc immediately. Instead, RPdoc opens the login 
dialog with the URL of RPRedirDoc and attaches the loginSessionToken L. RPRedirDoc is loaded from RP (|t] and 10 ) 
and redirects the login dialog to IdPdoc fill and [ja), passing the user’s email address, the tag, the FWD domain, and 
the iaKey from RP, as stored under the session key loginSessionToken , to IdPdoc. 1 

After the browser loaded IdPdoc from IdP, the user enters her password 2 matching her email address [L]. The 
password, the email address, the tag, and the FWD domain are now sent to IdP [S]. After IdP verified the user 
credentials [Ts], it creates the identity assertion as the signature 

ia := s\g((tag,email,FWDDomain) ,kidp) 

using its private signing key k\& p us and then returns ia to IdPdoc n. We note that ia contains the signature only, not 
the data that was signed. 

To avoid that the FWD learns the IA (we discuss this further in Section 2.4), IdPdoc now encrypts the IA using the 
iaKey [S]: 

eia := en c s (ia,iaKey) . 

Then, IdPdoc opens an iframe with the URL of FWDdoc, passing the tag and the encrypted IA to FWDdoc. After 
the iframe is loaded [20], FWDdoc sends a postMessage 3 to its parent’s opener window, which is RPdoc 21 . This 
postMessage with the sole content “ready” triggers RPdoc to send the tagKey to FWDdoc, where in the postMessage 
the origin 4 of FWD with HTTPS is declared to be the only allowed receiver of this message 5?. . FWDdoc uses the key 
to decrypt the tag and thereby learns the intended receiver (RP) of the IA [5). As its last action, FWD forwards the 
encrypted IA eia via postMessage to RPdoc (using RP’s HTTPS origin as the only allowed receiver) 24 . 

RPdoc receives eia and sends it along with the loginSessionToken to RP 39- RP then decrypts eia , retrieves ia' and 
checks whether ia' is a valid signature for (tag,email,FWDDomain) under the verification key pub (kjjp) of the IdP, 
where tag, email , and FWDDomain are taken from the session data identified by loginSessionToken 

Now, the user identified by the email address is logged in. The mechanism that is used to persist this logged-in state 
(if any) at this point is out of the scope of SPRESSO. In our analysis, as a model for a standard session-based login, 
we assume that RP creates a session for the user’s browser, identified by some freshly chosen token (the RP sendee 
token ) [27] and sends this token to the browser ]J|J. 


2.3 Implementation Details 

We developed a proof-of-concept implementation of SPRESSO in about 700 lines of JavaScript and HTML code. It 
contains all presented features of SPRESSO itself and a typical IdP. The implementation (source code and online demo) 
is available at [23]. Our model presented in Section 5 closely follows this implementation. 

The three servers (RP, IdP and FWD) are written in JavaScript and are based on node.js and its built-in crypto API. 
On the client-side we use the Web Cryptography API. For encryption we employ AES-256 in GCM mode to provide 
authenticity. Signatures are created/verified using RSA-SHA256. 

1 This data is passed to IdPdoc in the fragment identifier of the URL (a.k.a. hash), and therefore, it is not necessarily sent to IdP. 

2 In fact, the IdP can as well offer any other form of authentication, e.g., TLS client authentication or two-factor authentication. 

3 postMessages are messages that are sent between different windows in one browser. 

4 An origin is defined by a domain name plus the information whether the connection to this domain is via HTTP or HTTPS. 
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2.4 Discussion 


In order to provide more intuition and motivation for the design of SPRESSO, and in particular its security and 
privacy properties, we first informally discuss some potential attacks on our system and what measures we took when 
designing and implementing SPRESSO to prevent these attacks. These attacks also illustrate the complexity and 
difficulty of designing a secure and privacy-respecting web-based SSO system. In Sections 6 and 7, we formally prove 
that SPRESSO provides strong authentication and privacy properties in a detailed model of the web infrastructure. 
We also discuss other aspects of SPRESSO, including usability and performance. We conclude this section with a 
comparison of SPRESSO and BrowserlD. 

Malicious RP: Impersonation Attack. An attacker could try to launch a man in the middle attack against SPRESSO 
by playing the role of an RP (RP server and RPdoc) to the user. Such an attacker would run a malicious server at his 
RP domain, say, RPa, and also deliver a malicious script (instead of the honest RPdoc script) to the user’s browser. 
Now assume that the user wants to log in with her email address at RPa and is logged in at the IdP corresponding to 
the email address already. Then, the attacker (outside of the user’s browser) could first initiate the login process at 
RPb using the user’s email address. The attacker’s RP could then create a tag of the form enc s ((RPb, rpNonce) ,tagKey) 
using the domain of an honest RP RPb, instead of RPa. The IdP would hence create an IA for this tag and the user’s 
email address and deliver this IA to the user’s browser. If this IA were now indeed be delivered to the attacker’s RP 
window (which is running a malicious RPdoc script), the attacker could use the IA to finish the log in process at RPb 
(and obtain the service token from RPb), and thus, log in at RPb as the honest user. 

However, assuming that FWD is honest (see below for a discussion of malicious FWDs), FWD prevents this kind 
of attack: FWD forwards the (encrypted) IA via a postMessage only to the domain listed in the tag (so, in this case, 
RPb), which in the attack above is not the domain of the document loaded in the attacker’s RP window (RPa). The IA 
is therefore not transmitted to the attacker. The same applies when the attacker tries to navigate the RP window to its 
own domain, i.e., to RPa, before Step 24 . Our formal analysis presented in the following sections indeed proves that 
such attacks are excluded in SPRESSO. We note that in order to make sure that the postMessage is delivered to the 
correct RP window (technically, a window with the expected origin), FWD uses a standard feature of the postMessage 
mechanism which allows to specify the origin of the intended recipient of a postMessage. 

Malicious IdP. A malicious IdP could try to log the user in under an identity that is not her own. An attack of this kind 
on BrowserlD was shown in [10]. However, in SPRESSO, the IdP cannot select or alter the identity with which the 
user is logged in. Instead, the identity is fixed by RP after Step {g and checked in Step [26 . Again, our formal analysis 
shows that such attacks are indeed not possible in SPRESSO. 

The IdP could try to undermine the user’s privacy by trying to find out which RP requests the I A. However, in 
SPRESSO, the IdP cannot gather such information: From the information available to it (email, tag, FWDDomain plus 
any information it can gather from the browser’s state), it cannot infer the RP . 5 It could further try to corellate the 
sources and times of HTTPS requests for the support document with user logins. To minimize this side channel, we 
suggest caching the support document at each RP and automatic refreshing of this cache (e.g., an RP could cache the 
document for 48 hours and after that period automatically refresh the cache). Additionally, RPs should use the Tor 
network (or similar means) when retrieving the support document in order to hide their IP addresses. Assuming that 
support documents have been obtained from IdPs independently of specific login requests by users, our formal analysis 
shows that SPRESSO in fact enjoys a very strong privacy property (see Sections 4 and 6 ). 

In BrowserlD, malicious IdPs (in fact, any party who can run malicious scripts in the user’s browser) can check the 
presence or absence of certain iframes in the login process, leading to the privacy break mentioned earlier. Again, our 
formal analysis implies that this is not possible for SPRESSO. 

Malicious FWD. A malicious FWD could cooperate with or act as a malicious RP and thereby enable the man in the 
middle attack discussed above, undermining the authentication guarantees of the system. Also, a malicious FWD could 
collaborate with a malicious IdP and send information about the RP to the IdP, and hence, undermine privacy. 

5 If only a few RPs use a specific FWD, FWDDomain would reveal some information. However, this is easy to avoid in practice: 
the set of FWDs all (or many) RPs trust should be big enough and RPs could randomly choose one of these FWDs for every login 
process. 
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Therefore, for our system to provide authentication and privacy, we require that FWDs behave honestly. Below we 
discuss ways to force FWD to behave honestly. We suspect that there is no way to avoid the use of FWDs or other 
honest components in a practical SSO system which is supposed to provide not only authentication but also privacy: 
In our system, after Step 17 of the flow, IdPdoc must return the IA to the RP. There are two constraints: First, the IA 
should only be forwarded to a document that in fact is RP’s document. Otherwise, it could be misused to log in at RP 
under the user’s identity by any other party, which would break authentication. Second, RP’s identity should not be 
revealed to IdP, which is necessary for privacy. Currently, there is no browser mechanism to securely forward the IA to 
RP without disclosing RP’s identity to IdP (but see below). 

Enforcing Honest FWDs. Before we discuss existing and upcoming technologies to enforce honest behavior of FWDs, 
we first note that in SPRESSO, an FWD is chosen by the RP to which a user wants to log in. So the RP can choose 
the FWD it trusts. The RP certainly has a great interest in the trustworthiness of the FWD: As mentioned, a malicious 
FWD could allow an attacker to log in as an honest user (and hence, misuse RP’s service and undermine confidentiality 
and integrity of the user’s data stored at RP), something an RP would definitely want to prevent. Second, we also note 
that FWD does not learn a user’s email address: the IA, which is given to FWD and which contains the user’s email 
address, is encrypted with a symmetric key unknown to FWD. 6 Therefore, SPRESSO does not provide FWD with 
information to track at which RP a specific user logs in. 7 

Now, as for enforcing honest FWDs, first note that an honest FWD server is supposed to always deliver the same 
fixed JavaScript to a user’s browsers. This JavaScript code is very short (about 50 lines of code). If this code is used, 
it is not only ensured that FWD preserves authentication and privacy, but also that no tracking data is sent back to the 
FWD server. 

Using current technology, a user could use a browser extension which again would be very simple and which would 
make sure that in fact only this specific JavaScript is delivered by FWD (upon the respective request). As a result, FWD 
would be forced to behave honestly, without the user having to trust FWD. Another approach would be an extension 
that replaces FWD completely, which could also lead to a simplified protocol. In both cases, SPRESSO would provide 
authentication and privacy without having to trust any FWD. Both solutions have the common problem that they do not 
work on all platforms, because not on all platforms browsers support extensions. The first solution (i.e., the extension 
checks only that correct JavaScript is loaded) would at least still work for users on such platforms, albeit with reduced 
security and privacy guarantees. 

A native web technology called subresource integrity (SRI) 8 is currently under development at the W3C. SRI 
allows a document to create an iframe with an attribute integrity that takes a hash value. The browser now would 
guarantee that the document loaded into the iframe hashes to exactly the given value. So, essentially the creator of the 
iframe can enforce the iframe to be loaded with a specific document. This would enable SPRESSO to automatically 
check the integrity of FWDdoc without any extensions. 

Referer Header and Privacy. The Referer [sic!] header is set by browsers to show which page caused a navigation to 
another page. It is set by all common browsers. To preserve privacy, when the loading of IdPdoc is initiated by RPdoc, 
it is important that the Referer header is not set, because it would contain RP’s domain, and consequently, IdP would 
be able to read off from the Referer header to which RP the user wants to log in, and hence, privacy would be broken. 
With HTMF5, a special attribute for links in HTMF was introduced, which causes the Referer header to be suppressed 
(rel="noref errer"). However, when such a link is used to open a new window, the new window does not have a 
handle on the opening window (opener) anymore. But having a handle is essential for SPRESSO, as the postMessage 
in Step [ 21 ] is sent to the opener window of IdPdoc. To preserve the opener handle while at the same time hiding the 
referer, we first open the new window with a redirector document loaded from RP (Step [s} and then navigate this 
window to IdPdoc (using a link with the noreferrer attribute set and triggered by JavaScript in Step fiii l This causes the 


6 We note that IA is a signature anyway, so typically a signed hash of a message. Hence, for common signature schemes, already 
from the IA itself FWD is not able to extract the user’s email address. In addition, SPRESSO even encrypts the IA to make sure that 
this is the case no matter which signature scheme is used. 

1 A malicious FWD could try to set cookies and do browser fingerprinting to the track the behavior of specific browsers. Still it 
does not obtain the user’s email address. 

8 http://www.w3.org/TR/SRI/ 


10 



Referer header to be cleared, while the opener handle is preserved. 9 Our formal analysis implies that with this solution 
indeed privacy is preserved. 

Cross-Site Request Forgery. Cross-site request forgery is particularly critical at RP, where it could be used to log a 
user in under an identity that is not her own. For RP, SPRESSO therefore employs a session token that is not stored in 
a cookie, but only in the state of the JavaScript, avoiding cross-origin and cross-domain cookie attacks. Additionally, 
RP checks the Origin header of the login request to make sure that no login can be triggered by a third party (attacker) 
web page. Our formal analysis implies that cross-site request forgery and related attacks are not possible in SPRESSO. 

Phishing. It is important to notice that in SPRESSO the user can verify the location and TLS certificate of IdPdoc’s 
window by checking the location bar of her browser. The user can therefore check where she enters her password, 
which would not be possible if IdPdoc was loaded in an iframe. Setting strict transport security headers can further 
help in avoiding phishing attacks. 

Tag Length Side Channel. The length of the tag created in Step depends on the length of RPDomain. Since the tag 
is given to IdP, IdP might try to infer RPDomain from the length of the tag. However, according to RFC 1035, domain 
names may at most be 253 characters long. Therefore, by appropriate padding (e.g., encrypting always nine 256 Bit 
plaintext blocks) 10 the length of the tag will not reveal any information about RPDomain. 

Performance. SPRESSO uses only standard browser features, employs only symmetric encryption/decryption and 
signatures, and requires (in a minimal implementation) eight HTTPS requests/responses — all of which pose no 
significant performance overhead to any modern web application, neither for the browser nor for any of the servers. 
In our prototypical and unoptimized implementation, a login process takes less than 400 ms plus the time for entering 
email address and password. 

Usability. In SPRESSO, users are identified by their email addresses (an identifier many users easily memorize) and 
email providers serve as identity providers. Many web applications today already use the email address as the primary 
identifier along with a password for the specific web site: When a user signs up, a URL with a secret token is sent to 
the user’s email address. The user has to check her emails and click on the URL to confirm that she has control over the 
email address. She also has to create a password for this web site. SPRESSO could seamlessly be integrated into this 
sign up scheme and greatly simplify it: If the email provider (IdP) of the user supports SPRESSO, an SPRESSO login 
flow can be launched directly once the user entered her email address and clicked on the login button, avoiding the 
need for a new user password and the email confirmation; and if the user is logged in at the IdP already, the user does 
not even have to enter a password. Otherwise, or if a user has JavaScript disabled, an automatic and seamless fallback 
to the classical token-based approach is possible (as RP can detect whether the IdP supports SPRESSO in Step [J of 
the protocol). In contrast to other login systems, such as Google ID, the user would not even have to decide whether 
to log in with SPRESSO or not due to the described seamless integration of SPRESSO. Due to the privacy guarantees 
(which other SSO systems do not have), using SPRESSO would not be disadvantageous for the user as her IdPs cannot 
track to which RPs the user logs in. 

The above illustrates that, using SPRESSO, signing up to a web site is very convenient: The user just enters her 
email address at the RP’s web site and presses the login button (if already logged in at the respective IdP, no password 
is necessary). Also, with SPRESSO the user is free to use any of her email addresses. 

Extendability. SPRESSO could be extended to have the IdP sign (in addition to the email address) further user 
attributes in the IA, which then might be used by the RP. 

Operating FWD. Operating an FWD is very cheap, as the only task is to serve one static file. Any party can act as an 
FWD. Users and RPs might feel most confident if an FWD is operated by widely trusted non-profit organizations, such 
as Mozilla or the EFF. 

9 Another option would have been to use a data URI instead of loading the redirector document from RPdoc and to use a Refresh 
header contained in a meta tag for getting rid of the Referer header. This however showed worse cross-browser compatibility, and 
the Refresh header lacks standardization. 

10 Eight 256 bit blocks are sufficient for all domain names. We need an additional block for rpNonce. 


11 



Comparison with BrowserlD. BrowserlD was the first and so far only SSO system designed to provide privacy (IdPs 
should not be able to tell at which RPs user’s log in). Nonetheless, as already mentioned (see Section 2.1), severe 
attacks were discovered in [12] which show that the privacy promise of BrowserlD is broken: not only IdPs but even 
other parties can track the login behavior of users. Regaining privacy would have required a major redesign of the 
system, resulting in essentially a completely new system, as pointed out in [12]. Also, BrowserlD has the disadvantage 
that it relies on a single trusted server (login. persona.org) which is quite complex, with several server interactions 
necessary in every login process, and most importantly, by design, gets full information about the login behavior of 
users (the user’s email address and the RP at which the user wants to log in). 11 Finally, BrowserlD is a rather complex 
SSO system (with at least 64 network and inter-frame messages in a typical login flow 12 compared to only 19 in 
SPRESSO). This complexity implies that security vulnerability go unnoticed more easily. In fact, several attacks on 
BrowserlD breaking authentication and privacy claims were discovered (see [10,12]). 

This is why we designed and built SPRESSO from scratch, rather than trying to redesign BrowserlD. The design 
of SPRESSO is in fact very different to BrowserlD. For example, except for HTTPS and signatures of IdPs, SPRESSO 
uses only symmetric encryption, whereas in BrowserlD, users (user’s browers) have to create public/private key pairs 
and IdPs sign the user’s public keys. The entities in SPRESSO are different to those in BrowserlD as well, e.g., 
SPRESSO does not rely on the mentioned single, rather complex, and essentially omniscient trusted party, resulting in 
a completely different protocol flow. The design of SPRESSO is much slimmer than the one of BrowserlD. 


3 Web Model 

Our formal security analysis of SPRESSO (presented in the next sections) is based on the general Dolev-Yao style web 
model in [10]. As mentioned in the introduction, we changed some details in this model to facilitate the definition of 
indistinguishability/privacy properties (see Section 4). In particular, we simplified the handling of nonces and removed 
non-deterministic choices wherever possible. Also, we added the HTTP Referer header and the HTML5 noreferrer 
attribute for links. 

Here, we only present a very brief version of the web model. The full model, including our changes, is provided in 
Appendices A-C. 


3.1 Communication Model 

The main entities in the communication model are atomic processes, which are used to model web browsers, web 
servers, DNS servers as well as web and network attackers. Each atomic process listens to one or more (IP) addresses. 
A set of atomic processes forms what is called a system. Atomic processes can communicate via events, which consist 
of a message as well as a receiver and a sender address. In every step of a run, one event is chosen non-deterministically 
from the current “pool” of events and is delivered to one of the atomic processes that listens to the receiver address of 
that event. The atomic process can then process the event and output new events, which are added to the pool of events, 
and so on. More specifically, messages, processes, etc. are defined as follows. 

Terms, Messages and Events. As usual in Dolev-Yao models (see, e.g., [1]), messages are expressed as formal terms 
over a signature. The signature E for the terms and messages considered in the web model contains, among others, 
constants (such as (IP) addresses, ASCII strings, and nonces), sequence and projection symbols, and further function 
symbols, including those for (a)symmetric encryption/decryption and digital signatures. Messages are defined to be 
ground terms (terms without variables). For example (see also Section 2.2 where we already use the term notation to 
describe messages), pub(k) denotes the public key which belongs to the private key k. To provide another example of 
a message, in the web model, an HTTP request is represented as a ground term containing a nonce, a method (e.g., 

“In SPRESSO, we require that FWD behaves honestly. In a login process, however, the FWD server needs to provide only a 
fixed single and very simple JavaScript, no further server interaction is necessary. Also, FWD does not get full information and RP 
in every login process may choose any FWD it trusts. Moreover, as discussed above, there are means to force FWD to provide the 
expected JavaScript. 

12 Counting HTTP request and responses as well as postMessages, leaving out any user requests for GUI elements or other 
non-necessary resources. 
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GET or POST), a domain name, a path, URL parameters, request headers (such as Cookie), and a message body. For 
instance, an HTTP GET request for the URL http: //example. com/show?p=l is modeled as the term 

r := (HTTPReq,ni ,GET, example.com, /show, ((p, 1)), (),()), 

where headers and body are empty. An HTTPS request for r is of the form enc a ((r,k'}, pub(k eX ampie.com)). where k' is a 
fresh symmetric key (a nonce) generated by the sender of the request (typically a browser); the responder is supposed 
to use this key to encrypt the response. 

Events are terms of the form ( a,f,m ) where a and / are receiver/sender (IP) addresses, and m is a message, for 
example, an HTTP(S) message as above or a DNS request/response. 

The equationcil theory associated with the signature E is defined as usual in Dolev-Yao models. The theory induces 
a congruence relation = on terms. It captures the meaning of the function symbols in E. For instance, the equation in 
the equational theory which captures asymmetric decryption is dec a (enc a (x, pub(y)),y) =x. With this, we have that, 
for example, 

dec a (enc a ( (r, k '), pu b(k eX am P ie .com))) ^example.com) — (r. k ) , 

i.e., these two terms are equivalent w.r.t. the equational theory. 

Atomic Processes, Systems and Runs. Atomic Dolev-Yao processes, systems, and runs of systems are defined as 
follows. 

An atomic Dolev-Yao (DY) process is a tuple 


P = (I p >Z P ,R P ,Sq) 

where I p is the set of addresses the process listens to, Z p is a set of states (formally, terms), Sq £ Z p is an initial 
state, and R p is a relation that takes an event and a state as input and (non-deterministically) returns a new state and a 
sequence of events. This relation models a computation step of the process, which upon receiving an event in a given 
state non-deterministically moves to a new state and outputs a set of events. It is required that the events and states in 
the output can be computed (more formally, derived in the usual Dolev-Yao style) from the current input event and 
state. We note that in [10] the definition of an atomic process also contained a set of nonces which the process may use. 
Instead of such a set, we now consider a global sequence of (unused) nonces and new nonces generated by an atomic 
process are taken from this global sequence. 

The so-called attacker process is an atomic DY process which records all messages it receives and outputs all events 
it can possibly derive from its recorded messages. Hence, an attacker process is the maximally powerful DY process. It 
carries out all attacks any DY process could possibly perform and is parametrized by the set of sender addresses it may 
use. Attackers may corrupt other DY processes (e.g., a browser). 

A system is a set of atomic processes. A configuration (S,E,N) of this system consists of the current states of all 
atomic processes in the system (S), the pool of waiting events (E, here formally modeled as a sequence of events; 
in [10], the pool was modeled as a multiset), and the mentioned sequence of unused nonces ( N ). 

A run of a system for an initial sequence of events E° is a sequence of configurations, where each configuration 
(except for the initial one) is obtained by delivering one of the waiting events of the preceding configuration to an atomic 
process p (which listens to the receiver address of the event), which in turn performs a computation step according to 
its relation R p . The initial configuration consists of the initial states of the atomic processes, the sequence E°, and an 
initial infinite sequence of unused nonces. 

Scripting Processes. The web model also defines scripting processes, which model client-side scripting technologies, 
such as JavaScript. 

A scripting process (or simply, a script ) is defined similarly to a DY process. It is called by the browser in which 
it runs. The browser provides it with state information s, and the script then, according to its computation relation, 
outputs a term s', which represents the new internal state and some command which is interpreted by the browser (see 
also below). Again, it is required that a script’s output is derivable from its input. 

Similarly to an attacker process, the so-called attacker script R M may output everything that is derivable from the 
input. 
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3.2 Web System 

A web system formalizes the web infrastructure and web applications. Formally, a web system is a tuple 

(T^,S, script, E°) 


with the following components: 

• The first component, ‘W, denotes a system (a set of DY processes as defined above) and contains honest processes, 
web attacker, and network attacker processes. While a web attacker can listen to and send messages from its 
own addresses only, a network attacker may listen to and spoof all addresses (and therefore is the maximally 
powerful attacker). Attackers may corrupt other parties. In the analysis of a concrete web system, we typically 
have one network attacker only and no web attackers (as they are subsumed by the network attacker), or one or 
more web attackers but then no network attacker. Honest processes can either be web browsers, web servers, or 
DNS servers. The modeling of web servers heavily depends on the specific application. The web browser model, 
which is independent of a specific web application, is presented below. 

• The second component, S, is a finite set of scripts, including the attacker script R att . In a concrete model, such 
as our SPRESSO model, the set S \ {/( atl } describes the set of honest scripts used in the web application under 
consideration while malicious scripts are modeled by the “worst-case” malicious script, R att . 

• The third component, script, is an injective mapping from a script in S to its string representation script(.v) (a 
constant in E) so that it can be part of a messages, e.g., an HTTP response. 

• Finally, E° is a sequence of events, which always contains an infinite number of events of the form (a, a, TRIGGER) 
for every IP address a in the web system. 

A run of the web system is a run of “W initiated by E°. 

3.3 Web Browsers 

We now sketch the model of the web browser, with full details provided in Appendix C. A web browser is modeled as 
aDY process (I p ,Z P ,R P ,Sq). 

An honest browser is thought to be used by one honest user, who is modeled as part of the browser. User actions 
are modeled as non-deterministic actions of the web browser. For example, the browser itself non-deterministically 
follows the links in a web page. User data (i.e., passwords and identities) is stored in the initial state of the browser and 
is given to a web page when needed, similar to the AutoFill feature in browsers. 

Besides the user identities and passwords, the state of a web browser (modeled as a term) contains a tree of open 
windows and documents, lists of cookies, localStorage and sessionStorage data, a DNS server address, and other data. 

In the browser state, the windows subterm is the most complex one. It contains a window subterm for every open 
window (of which there may be many at a time), and inside each window, a list of documents, which represent the 
history of documents that have been opened in that window, with one of these documents being active, i.e., this 
document is presented to the user and ready for interaction. A document contains a script loaded from a web server 
and represents one loaded HTML page. A document also contains a list of windows itself, modeling iframes. Scripts 
may, for example, navigate or create windows, send XHRs and postMessages, submit forms, set/change cookies, 
localStorage, and sessionStorage data, and create iframes. When activated, the browser provides a script with all data 
it has access to, such as a (limited) view on other documents and windows, certain cookies as well as localStorage and 
sessionStorage. 

Figure 2 shows a brief overview of the browser relation R p which defines how browsers behave. For example, when 
a TRIGGER message is delivered to the browser, the browser non-deterministically choses an action. If, for instance, 
this action is 1, then an active document is selected non-deterministically, and its script is triggered. The script (with 
inputs as outlined above), can now output a command, for example, to follow a hyperlink (HREF). In this case, the 
browser will follow this link by first creating a new DNS request. Once a response to that DNS request arrives, the 
actual HTTP request (for the URL defined by the script) will be sent out. After a response to that HTTP request arrives, 
the browser creates a new document from the contents of the response. Complex navigation and security rules ensure 
that scripts can only manipulate specific aspects of the browser’s state. Browsers can become corrupted, i.e., be taken 
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Processing Input Message m 


m = FULLCQRRUPT: isCorrupted := FULLCORRUPT 
m = CLOSECORRUPT: isCorrupted := CLOSECORRUPT 
m = TRIGGER: non-deterministically choose action from {1,2,3} 
action = 1: Call script of some active document. 

Outputs new state and command, 
command = HREF: —> Initiate request 

command = IFRAME: Create subwindow, — > Initiate request 
command = FORM: —> Initiate request 
command = SETSCRIPT: Change script in given document. 
command = SETSCRIPTSTATE: Change state of script 

in given document. 
command = XMLHTTPREQUEST: — > Initiate request 
command = BACK or FORWARD: Navigate given window. 
command = CLOSE: Close given window. 
command = POSTMESSAGE: Send postMessage to specified 
document. 

action = 2: — > Initiate request to some URL in new window 
action = 3: —» Reload some document 
m = DNS response: send corresponding HTTP request 
m = HTTP(S) response: (decrypt,) find reference. 
reference to window: create document in window 
reference to document: add response body to document’s 
script input 

Fig. 2. The basic structure of the web browser relation R p with an extract of the most important processing steps, in the case that 
the browser is not already corrupted. 


overby web and network attackers. The browser model comprises two types of corruption: close-corruption, modeling 
that a browser is closed by the user, and hence, certain data is removed (e.g., session cookies and opened windows), 
before it is taken over by the attacker, and full corruption, where no data is removed in advance. Once corrupted, the 
browser behaves like an attacker process. 

4 Indistinguishability of Web Systems 

We now define the indistinguishability of web systems. This definition is not tailored towards a specific web application, 
and hence, is of independent interest. 

Our definition follows the idea of trace equivalence in Dolev-Yao models (see, e.g., [9]), which in turn is an abstract 
version of cryptographic indistinguishability. 

Intuitively, two web systems are indistinguishable if the following is true: whenever the attacker performs the same 
actions in both systems, then the sequence of messages he obtains in both runs look the same from the attacker’s point 
of view, where, as usual in Dolev-Yao models, two sequences are said to “look the same” when they are statically 
equivalent [1] (see below). More specifically, since, in general, web systems allow for non-deterministic actions (also 
of honest parties), the sequence of actions of the attacker might induce a set of runs. Then indistinguishability says that 
for all actions of the attacker and for every run induced by such actions in one system, there exists a run in the other 
system, induced by the same attacker actions, such that the sequences of messages the attacker obtains in both runs 
look the same to the attacker. 

Defining the actions of attackers in web systems requires care because the attacker can control different components 
of such a system, but some only partially: A web attacker (unlike a network attacker) controls only part of the network. 
Also an attacker might control certain servers (web servers and DNS servers) and browsers. Moreover, he might control 
certain scripts running in honest browsers, namely all attacker scripts /? att running in browsers; dishonest browsers are 
completely controlled by the attacker anyway. 
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We model a single action of the attacker by what we call a (web system) command ; not to be confused with 
commands output by a script to the browser. A command is of the form 

(i• j: ^process? CWld$ witch 5 C/ 71 ^/window 5 ^script 5 Uft) . 

The first component i £ N determines which event from the pool of events is processed. If this event could be delivered 
to several processes (recall that a network attacker, if present, can listen to all addresses), then j determines the process 
which actually gets to process the event. Now, there are different cases depending on the process to which the event is 
delivered and depending on the event itself. We denote the process by p and the event by e: i) If p is corrupted (it is a 
web attacker, network attacker, some corrupted browser or server), then the new state of this process and its output are 
determined by the term T process , i.e., this term is evaluated with the current state of the process and the input e. ii) If p 
is an honest browser and e is not a trigger message (e.g., a DNS or HTTP(S) response), then the browser processes e 
as usual (in a deterministic way), iii) If p is an honest browser and e is a trigger message, then there are three actions 
a browser can (non-deterministically) choose from: open a new window, reload a document, or run a script. The term 
CTH£/ sw itch £ {1,2,3} selects one of these actions. If it chooses to open a new window, a document will be loaded from 
the URL url. In the remaining two cases, cnicl wlm i (m determines the window which should be reloaded or in which a 
script is executed. If a script is executed and this script is the attacker script, then the output of this script is derived 
(deterministically) by the term r SCIapt , i.e., this term is evaluated with the data provided by the browser. The resulting 
command, if any, is processed (deterministically) by the browser. If the script to be executed is an honest script (i.e., 
not R att ), then this script is evaluated and the resulting command is processed by the browser. (Note that the script 
might perform non-deterministic actions.) iv) If p is an honest process (but not a browser), then the process evaluates e 
as usual. (Again, the computation might be non-deterministic, as honest processes might be non-deterministic.) 

We call a finite sequence of commands a schedule. Given a web system “WS = (TL, S, script, E°), a schedule a 
induces a set of (finite) runs in the obvious way. We denote this set by n ( ‘H-’S). Intuitively, a schedule models the 
attacker actions in a run. Note that we consider a very strong attacker. He not only determines the actions of all 
dishonest processes and all attacker scripts, but also schedules all events, not only events intended for the attacker; 
clearly, the attacker does not get to see explicitly events not intended for him. 

Before we can define indistinguishability of two web systems, we need to, as mentioned above, recall the definition 
of static equivalence of two messages t\ and to- We say that the messages 1 1 and ?2 are statically equivalent , written 
1 1 « ? 2 , if and only if, for all terms M(x ) and N (x) which contain one variable x and do not use nonces, we have that 
M(t i) = N(t i) iff M(tf) = Nfa). That is, every test performed by the attacker yields the same result for t\ and t 2 , 
respectively. For example, if k and k' are nonces, and r and r are different constants, then 

enc a ((r,k'),pub(k)) sa enc a ((r',k'), pub(k)) . 

Intuitively, this is the case because the attacker does not know the private key k. 

We also need the following terminology. If (W,S, script, E°) is a web system and p is an attacker process in Tf 1 , 
then we say that (ff,S, script, E°,p) is a web system with a distinguished attacker process p. If p is a finite run of this 
system, we denote by p(p) the state of p at the end of this run. In our indistinguishability definition, we will consider 
the state of the distinguished attacker process only. This is sufficient since the attacker can send all its data to this 
process. 

Now, we are ready to define indistinguishability of web systems in a natural way. 

Definition 1. Let “WSo and WS\ be two web system each with a distinguished attacker process po and pi, respectively. 
We say that these systems are indistinguishable, written WSo ~ ‘kfSi, iff for every schedule a and every i £ {0,1}, we 
have that for every run p £ o(‘WSi) there exists a run p' £ a(WSi^i) such that p(pf) ~ p'(pi -<). 


5 Formal Model of SPRESSO 

We now present the formal model of SPRESSO, which closely follows the description in Section 2 and the implemen¬ 
tation of the system. This model is the basis for our formal analysis of privacy and authentication properties presented 
in Sections 6 and 7. 
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Fig. 3. List of scripts in S and their respective string representations. 


We model SPRESSO as a web system (in the sense of Section 3.2). We call $WS = (TP, S, script, E°) an SPRESSO 
web system if it is of the form described in what follows. 

The set W = Hon U WebU Net consists of a finite set of web attacker processes (in Web), at most one network 
attacker process (in Net), a finite set FWD of forwarders, a finite set B of web browsers, a finite set RP of web servers 
for the relying parties, a finite set IDP of web servers for the identity providers, and a finite set DNS of DNS servers, 
with Hon := BU RPUIDPU FWDU DNS. Figure 7 shows the set of scripts S and their respective string representations 
that are defined by the mapping script. The set E° contains only the trigger events as specified in Section 3.2. 

We now sketch the processes and the scripts in TF and S (see Appendix D for full details). As mentioned, our 
modeling closely follows the description in Section 2 and the implementation of the system: 

• Browsers (in B) are defined as described in Section 3.3. 

• A relying party (in RP) is a web server. RP knows four distinct paths: /, where it serves the index web page 
(script_rp), /startLogin, where it only accepts POST requests and mainly issues a fresh RP nonce, /redir, 
where it only accepts requests with a valid login session token and serves script_rp_redir to redirect the browser 
to the IdP, and /login, where it also only accepts POST requests with login data obtained during the login process 
by script_rp running in the browser. It checks this data and, if the data is considered to be valid, it issues a service 
token. The RP keeps a list of such tokens in its state. Intuitively, a client having such a token can use the service of 
the RP. 

• Each IdP (in IDP) is a web server. It knows three distinct paths: /.well-known/spresso-login, where it serves 
the login dialog web page (script_idp), /.well-known/spresso-inf o, where it serves the support document 
containing its public key, and /sign, where it issues a (signed) identity assertion. Users can authenticate to the IdP 
with their credentials and IdP tracks the state of the users with sessions. Only authenticated users can receive IAs 
from the IdP. 

• Forwarders (in FWD) are web servers that have only one state (i.e., they are stateless) and serve only the script 
script_f wd, except if they become corrupted. 

• Each DNS server (in DNS) contains the assignment of domain names to IP addresses and answers DNS requests 
accordingly. 

Besides the browser, RPs, IdPs, and FWDs can become corrupted: If they receive the message CORRUPT, they start 
collecting all incoming messages in then' state and when triggered send out some message that is derivable from their 
state and collected input messages, just like an attacker process. 

6 Privacy of SPRESSO 

In our privacy analysis, we show that an identity provider in SPRESSO cannot learn where its users log in. We formalize 
this property as an indistinguishability property: an identity provider (modeled as a web attacker) cannot distinguish 
between a user logging in at one relying party and the same user logging in at a different relying party. 

Definition of Privacy of SPRESSO. The web systems considered for the privacy of SPRESSO are the web systems 
SWS defined in Section 5 which now contain one or more web attackers, no network attackers, one honest DNS 
server, one honest forwarder, one browser, and two honest relying parties r i and ri. All honest parties may not become 
corrupted and use the honest DNS server for address resolving. Identity providers are assumed to be dishonest, and 
hence, are subsumed by the web attackers (which govern all identities). The web attacker subsumes also potentially 
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dishonest forwarders, DNS servers, relying parties, and other servers. The honest relying parties are set up such that 
they already contain the public signing keys (used to verify identity assertions) for each domain registered at the DNS 
server, modeling that these have been cached by the relying parties, as discussed in Section 2.2. 

In order to state the privacy property, we replace the (only) honest browser in the above described web systems 
by a slightly extended browser, which we call a challenge browser: This browser may not become corrupted and is 
parameterized by a domain r of a relying party. When it is to assemble an HTTP(S) request for the special domain 
CHALLENGE, then instead of putting together and sending out the request for CHALLENGE it takes the domain r. However, 
this is done only for the first request to CHALLENGE. Further requests to this domain are not altered (and would fail, as 
the domain CHALLENGE is not listed in the honest DNS server). 

We denote web systems as described above by $WS pnv (r), where r is the domain of the relying party given to the 
challenge browser in this system. 

We can now define privacy of SPRESSO. We note that it is not important which attacker process in SWS pnv {■ ) is 
the distinguished one (in the sense of Section 4). 

Definition 2. We say that SPRESSO is IdP-private iff for every web system SffS p " v (-) and domains r \ and r 2 of 
relying parties as described above, we have that SWS pm (rj) ss STffS p " v {rf), i.e., SWS pm (rj) and STffS p "' are 
indistinguishable. 

Note that there are many different situations where the honest browser in SVfS p "' {■) could be triggered to send an 
HTTP(S) request to CHALLENGE. This could, for example, be triggered by the user who enters a URL in the location 
bar of the browser, a location header (e.g., determined by the adversary), an (attacker) script telling the browser to 
follow a link or create an iframe, etc. 

Now, the above definition requires that in every stage of a run and no matter how and by whom the CHALLENGE 
request was triggered, no (malicious) IdP can tell whether CHALLENGE was replaced by r\ or ro, i.e., whether this 
resulted in a login request for r\ or r 2 . Recall that the CHALLENGE request is replaced by the honest browser only once. 
This is the only place in a run where the adversary does not know whether this is a request to r\ or r 2 . Other requests 
in a run, even to both r\ and ro. the adversary can determine. Still, he should not be able to figure out what happened in 
the CHALLENGE request. Hence, this definition captures in a strong sense the intuition that a malicious IdP should not 
be able to distinguish whether a user logs in/has logged in at r\ or ro. 

Analyzing Privacy of SPRESSO. The following theorem says that SPRESSO enjoys the described privacy definition. 
Theorem 1. SPRESSO is IdP-private. 

The full proof is provided in Appendix H. In the proof, we define an equivalence relation between configurations of 
SWS P '" (n) and SWS P "' {rf), comprising equivalences between states and equivalences between events (in the pool of 
waiting events). For the states, for each (type of an) atomic DY process in the web system, we define how their states 
are related. For example, the state of the FWD server must be identical in both configurations. As another example, 
roughly speaking, the attacker’s state is the same up to subterms the attacker cannot decrypt. Regarding (waiting) 
events, we distinguish between messages that result (directly or indirectly) from a CHALLENGE request by the browser 
and other messages. While the challenged messages may differ in certain ways, other messages may only differ in parts 
that the attacker cannot decrypt. 

Given these equivalences, we then show by induction and an exhaustive case distinction that, starting from equiva¬ 
lent configurations, every schedule leads to equivalent configurations. (We note that in SWS P "' (•) a schedule induces 
a single run because in SWS P "' '(•) we do not have non-deterministic actions that are not determined by a schedule: 
honest servers and scripts perform only deterministic actions.) As an example, we distinguish between the potential 
receivers of an event. If, e.g., FWD is a receiver of a message, given its identical state in both configurations (as per the 
equivalence definition) and the equivalence on the input event, we can immediately show that the equivalence holds on 
the output message and state. For other atomic DY processes, such as browsers and RPs, this is much harder to show. 
For example, for browsers, we need to distinguish between the different scripts that can potentially run in the browser 
(including the attacker script), the origins under which these scripts run, and the actions they can perform. 

For equivalent configurations of SWS P "' (n) and SWS P "' (V 2 ), we show that the attacker’s views are indistinguish¬ 
able. Given that for all SWS pm (r\ ) and SWS pm ’ (rf) every schedule leads to equivalent configurations, we have that 
SPRESSO is IdP-private. 
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7 Authentication of SPRESSO 


We show that SPRESSO satisfies two fundamental authentication properties. 

Formal Model of SPRESSO for Authentication. For the authentication analysis, we consider web systems as defined 
in Section 5 which now contain one network attacker, a finite set of browsers, a finite set of relying parties, a finite set 
of identity providers, and a finite set of forwarders. Browsers, forwarders, and relying parties can become corrupted by 
the network attacker. The network attacker subsumes all web attackers and also acts as a (dishonest) DNS server to all 
other parties. We denote a web system in this class of web systems by SWS m ' th ■ 

Defining Authentication for SPRESSO. We state two fundamental authentication properties every SSO system should 
satisfy. These properties are adapted from [10]. 

Informally, these properties can be stated as follows: (A) The attacker should not be able to use a service of an 
honest RP as an honest user. In other words, the attacker should not get hold of (be able to derive from his current 
knowledge) a service token issued by an honest RP for an ID of an honest user (browser), even if the browser was 
closed and then later used by a malicious user, i.e., after a CL0SEC0RRUPT (see Section 3.3). (B) The attacker should 
not be able to authenticate an honest browser to an honest RP with an ID that is not owned by the browser (identity 
injection). For both properties, we clearly have to require that the forwarder used by the honest RP is honest as well. 

We call a web system SWS""' h secure w.r.t. authentication if the above conditions are satisfied in all runs of the 
system. We refer the reader to Appendix E for the formal definition of (A) and (B). 

Analyzing Authentication of SPRESSO. We prove the following theorem: 

Theorem 2. Let SWS a " ,h be an SPRESSO web system as defined above. Then SWS a “ ,h is secure w.r.t. authentication. 

In other words, the authentication properties (A) and (B) are fulfilled for every SPRESSO web system. 

For the proof, we first show some general properties of SVfS auth . In particular, we show that encrypted commu¬ 
nication over HTTPS between an honest relying party and an honest IdP cannot be altered by the (network) attacker, 
and, based on that, any honest relying party always retrieves the “correct” public signature verification key from honest 
IdPs. We then proceed to show that for a service token to be issued by an honest RP, a request of a specific form has to 
be received by the RP. 

We then use these properties and the general web system properties shown in the full version of [12] to prove 
properties (A) and (B) separately. In both cases, we assume that the respective property is not satisfied and lead this to 
a contradiction. Again, the full proof is provided in Appendix F. 


8 Further Related Work 

As mentioned in the introduction, many SSO systems have been developed. However, unlike SPRESSO, none of them 
is privacy-respecting. 

Besides the design and implementation of SPRESSO, the formal analysis of this system based on an expressive web 
model is an important part of our work. The formal treatment of the security of web applications is a young discipline. 
Of the few works in this area even less are based on a general model that incorporates essential mechanisms of the web. 
Early works in formal web security analysis (see, e.g., [3, 8,16,17, 25]) are based on very limited models developed 
specifically for the application under scrutiny. The first work to consider a general model of the web, written in the 
finite-state model checker Alloy, is the work by Akhawe et al. [2]. Inspired by this work, Bansal et al. [5,6] built a more 
expressive model, called WebSpi, in ProVerif [7], a tool for symbolic cryptographic protocol analysis. These models 
have successfully been applied to web standards and applications. Recently, Kumar [18] presented a high-level Alloy 
model and applied it to SAML single sign-on. The web model presented in [10], which we further extend and refine 
here, is the most comprehensive web model to date (see also the discussion in [10]). In fact, this is the only model 
in which we can analyze SPRESSO. For example, other models do not incorporate a precise handling of windows, 
documents, or iframes; cross-document messaging (postMessages) are not included at all. 
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9 Conclusion 


In this paper, we proposed the first privacy-respecting (web-based) SSO system, where the IdP cannot track at which 
RP a user logs in. Our system, SPRESSO, is open and decentralized. Users can log in at any RP with any email address 
with SPRESSO support, allowing for seamless and convenient integration into the usual login process. Being solely 
based on standard HTML5 and web features, SPRESSO can be used across browsers, platforms, and devices. 

We formally prove that SPRESSO indeed enjoys strong authentication and privacy properties. This is important 
since, as discussed in the paper, numerous attacks on other SSO systems have been discovered. These attacks demon¬ 
strate that designing a secure SSO system is non-trivial and security flaws can easily go undetected when no rigorous 
analysis is carried out. 

As mentioned in Section 8, there have been only very few analysis efforts, based on expressive models of the web 
infrastructure, on web applications in general and SSO systems in particular in the literature so far. Therefore, the 
analysis carried out in this paper is also of independent interest. 

Our work is the first to analyze privacy properties based on an expressive web model, in fact the most expressive 
model to date. The general indistinguishability/privacy definition we propose, which is not tailored to any specific web 
application, will be useful beyond the analysis performed in this paper. 
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A The Web Model 

In this section, we present the model of the web infrastructure as proposed in [10] and [11], along with the following 
changes and additions: 

• The set of waiting events is replaced by a (infinite) sequence of waiting events. The sequence initially only contains 
an infinite number of trigger events (interleaved by receiver). All new events output by processes are added in the 
front of the sequence. 
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• We write events as terms, i.e., ( a:f:m ) becomes (a,f,m). 

• Eq and E in runs/processing steps are now infinite sequences instead of multi-sets. 

• In runs, the index of states and events (and nonces) are now written superscript (instead of subscript). 

• For atomic DY processes, we replace the set of output messages by a sequence term (as defined in the equational 
theory) of the form (( a,f,m), (a 1 , f ,m !),...). Each time such a sequence is output by any DY process, its elements 
are prepended to the sequence of waiting events. 

• We introduce a global sequence of nonces (ni,«2,...). Whenever any DY process outputs special placeholders 
iq,z/2,... (in its state or output messages), these placeholders are replaced by freshly chosen nonces from the 
global set of nonces. 

• A similar approach applies to scripts (running inside browsers). Instead of receiving and using a fresh set of nonces 

each time they are called by the browser, scripts now get no dedicated set of nonces as inputs, but instead may 
output operators After the script run has finished, these are replaced by “fresh” v placeholders by the 

browser (i.e., v placeholders the browser itself does not use otherwise.) 

• We therefore remove the sets of nonces from DY processes. 

• We remove the function symbol extractmsg(-) which extracted the signed term from a signature. Instead, we added 
a new function symbol checksig(-, •, •) that checks that a given term was signed. 

• For an accurate privacy analysis, we introduce the Referer 13 header and associated document property. We also 
introduce the location document property. 

• For the script command for following a link (HREF) we add the option to avoid sending the referer header (as a 
model for the rel="noref errer" attribute for links in HTML5). 14 

• DNS responses now not only contain the IP address of the domain for which the DNS request was sent, but also 
the domain itself. This is a more realistic model. 


A.l Communication Model 

We here present details and definitions on the basic concepts of the communication model. 

Terms, Messages and Events The signature E for the terms and messages considered in this work is the union of the 
following pairwise disjoint sets of function symbols: 

• constants C = IPsUSU{T,_L,0} where the three sets are pairwise disjoint, S is interpreted to be the set of ASCII 
strings (including the empty string e), and I Ps is interpreted to be a set of (IP) addresses, 

• function symbols for public keys, (a)symmetric encryption/decryption, and signatures: pub(-), enc a (-, •), dec a (-, •), 
enc s (v), dec 5 (-, •), sig(-, •), checksig(-, •), and extractmsg(-), 

• n-ary sequences (),(•), (■, •), etc., and 

• projection symbols 7r,(-) for all i G N. 

For strings (elements in S), we use a specific font. For example, HTTPReq and HTTPResp are strings. We denote by 
Doms C S the set of domains, e.g., example.com G Doms. We denote by Methods C § the set of methods used in 
HTTP requests, e.g., GET, POST G Methods. 

The equational theory associated with the signature E is given in Figure 4. 

Definition 3 (Nonces and Terms). By X = {xq,x\ , ■ • ■} we denote a set of variables and by 9f we denote an infinite 
set of constants (nonces) such that E, X, and are pairwise disjoint. For N C we define the set c Tn(X) of terms 
over E UNUX inductively as usual: (1) Ift G NUX, then t is a term. (2) If f G E is an n-ary function symbol in E for 
some n > 0 and 1 1 ,..., t n are terms, then f(t \,..., t n ) is a term. 

By = we denote the congruence relation on ‘T^f X) induced by the theory associated with E. For example, we have 
that 7Ti(dec a (enc a ((a,b), pub(k)),k)) = a. 

13 A spelling error in the early HTTP standards. 

14 Note that in practice, all major browsers except for the Internet Explorer support this property. 
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dec a (enc a (x,pub(y)),y) =x (1) 

dec s (enc s (-v,v),y) =x (2) 

checksig(sig(x,y),jr, pub(y)) = T (3) 

7r/((xi, • • ■ ,x„)) = Xj if 1 < i < n (4) 

n j({ x l i ■ , x n)) = 0 if j & (5) 


Fig. 4. Equational theory for L. 


Definition 4 (Ground Terms, Messages, Placeholders, Protomessages). By % = %/(</)), we denote the set of all 

terms over E UN without variables, called ground terms. The set fM of messages (over 9fj is defined to be the set of 
ground terms ‘2^. 

We define the set V pr0 cess = {vi,vi, ■ ■ • } of variables (called placeholders). The set ‘M u := %^(V process ) is called 
the set of protomessages, i.e., messages that can contain placeholders. 

Example 1. For example, k £ tIf and pub(fc) are messages, where k typically models a private key and pub(k) the 
corresponding public key. For constants a , b , c and the nonce k £ the message enc a ((a,b,c), pub(k)) is interpreted 
to be the message (a,b,c) (the sequence of constants a, b, c ) encrypted by the public key pub(k). 

Definition 5 (Normal Form). Let t be a term. The normal form of t is acquired by reducing the function symbols 
from left to right as far as possible using the equational theory shown in Figure 4. For a term t, we denote its normal 
form as /J,. 

Definition 6 (Pattern Matching). Let pattern £ ‘T^r ({ * }) be a term containing the wildcard (variable *). We say that 
a term t matches pattern iff t can be acquired from pattern by replacing each occurrence of the wildcard with an 
arbitrary term (which may be different for each instance of the wildcard). We write t ~ pattern. 

For a term t' we write t'\pattern to denote the term that is acquired from t' by removing all immediate subterms of 
t' that do not match pattern. 

Example 2. For example, for a pattern p = (T, *) we have that (T,42) ~ p, (_L,42) fi* p, and 

«-L]T),(T,23),(a,b),(T,_L))|p = ((T,23),(T,-L)) . 

Definition 7 (Variable Replacement). LetN C t £ 'Zv({a'i , ■.. ,x n }), and fi.....f„ £ ‘ff. By r[t\/x \,... ,t n /x„\ we 
denote the (ground) term obtained from r by replacing all occurrences ofXi in r by tj, for all i £ {1,...,«}. 

Definition 8 (Events and Protoevents). An event (over IPs and 9f) is a term of the form la. f .ni), for a, f £ IPs and 
m £ Af, where a is interpreted to be the receiver address and f is the sender address. We denote by F the set of all 
events. Events over IPs and k\f u are called protoevents and are denoted F v . By 2 £ ^ (or 2^, respectively) we denote 
the set of all sequences of (proto)events, including the empty sequence (e.g., (), ((a,f,m), (a 1 ,/ / ,m'),...), etc.). 

Atomic Processes, Systems and Runs 

An atomic process takes its current state and an event as input, and then (non-deterministically) outputs a new state 
and a set of events. 

Definition 9 (Generic Atomic Processes and Systems). A (generic) atomic process is a tuple p = (I p ,Z P ,R P ,Sq) 
where I p C IPs, Z p £ is a set of states, R p C (fE x Z p ) x (2 eV ^ x r L^(y pmcess )) (input event and old state map to 
sequence of output events and new state), and s g £ Z p is the initial state of p. For any new state s and any sequence of 
nonces ( 771 , 772 , •■■) we demand that 5 [ 771 / 7 / 1 , 772 /^ 2 , ■ ■ ■] G Z p . A system fP is a (possibly infinite) set of atomic processes. 

Definition 10 (Configurations). A configuration of a system ‘1’ is a tuple (S.E.N) where the state of the system S maps 
every atomic process p £ T to its current state S(p) £ Z p , the sequence of waiting events E is an infinite sequence 15 
(ei ,e 2 , ■ • •) of events waiting to be delivered, and N is an infinite sequence of nonces ( 111 , 112 ,...). 

15 Here: Not in the sense of terms as defined earlier. 
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Definition 11 (Concatenating sequences). For a term a = (a\, ... ,a ( ) and a sequence b = (b\ .bo- ■ ■ ■), we define the 
concatenation as a- b := (ai ,... ,a;, b\,b 2 , ■ ■ ■ )• 

Definition 12 (Subtracting from Sequences). For a sequence X and a set or sequence Y we define X \ Y to be the 
sequence X where for each element in Y, a non-deterministically chosen occurence of that element in X is removed. 

Definition 13 (Processing Steps). A processing step of the system P is of the form 

(S,E,N) - - — 4 (S',E',N') 

P^Eout 


where 

1. ( S,E,N ) and (S' 1 E’,N') are configurations of P, 

2. e, n = (a,f,m) G E is an event, 

3. p G P is a process, 

4. E out is a sequence (term) of events 

such that there exists 

1. a sequence (term) Ef ul C 2 E ' ® of protoevents, 

2. a term s G process)* 

3. a sequence (i ; i,v ; 2 ,... ,v,-) of all placeholders appearing in Ef ut (ordered lexicographically), 

4. a sequence N v = (rp, rp, ..., ry,) of the first i elements in N 

with 

1. (( e in ,S(p)),(EZ ut ,s v )) G RP and a G I p , 

2. E out = Eg Ut [mi/vi,...,nii/vi] 

3. S'(p) = s v [mi/v\,.. ., nij/vi] and S'(p') = S(p') for all p' p 

4. E'= E our (E\{e in }) 

5. N' =N\N V 

We may omit the superscript and/or subscript of the arrow. 

Intuitively, for a processing step, we select one of the processes in P, and call it with one of the events in the list of 
waiting events E. In its output (new state and output events), we replace any occurences of placeholders v x by “fresh” 
nonces from N (which we then remove from N). The output events are then prepended to the list of waiting events, and 
the state of the process is reflected in the new configuration. 

Definition 14 (Runs). Let P be a system, F {> be sequence of events, and N° be a sequence of nonces. A run p of a system 
P initiated by E° with nonces N° is a finite sequence of configurations ((S°,E°,N 0 ),..., (S n ,E n ,N n )) or an infinite 
sequence of configurations ((S° ,E° ,N °),...) such that S°(p) = s^for all p G P and (S’ ,E' ,N’) —> (S i+1 ,E i+l 
for all 0 i < n (finite run) or for oil / ^ 0 (infinite run). 

We denote the state S n (p) of a process p at the end of a run p by p(p). 

Usually, we will initiate runs with a set E° that contains infinite trigger events of the form (a, a, TRIGGER) for each 
a G IPs, interleaved by address. 

Atomic Dolev-Yao Processes We next define atomic Dolev-Yao processes, for which we require that the messages 
and states that they output can be computed (more formally, derived) from the current input event and state. For this 
purpose, we first define what it means to derive a message from given messages. 

Definition 15 (Deriving Terms). Let M be a set of ground terms. We say that a term m can be derived from M with 
placeholders V if there exist n >0, mi,... ,m n G M, and r G Tj) ({x |,... ,x„} UV) such that m = r[m\ jx\ ,..., m„ /x n \. 
We denote by dy(M) the set of all messages that can be derived from M with variables V. 

For example, a G <f.iq({enc a ((a,fo,c),pub(£)),A:}). 
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Definition 16 (Atomic Dolev-Yao Process). An atomic Dolev-Yao process (or simply, a DY process) is a tuple 
p = (I P ,Z P , R p ,Sq) such that (I p ,Z P ,R P ,Sq) is an atomic process and (1) Z p C (and hence, Sq G %il), an d (2) for 
all events sequences of protoevents E, s £ s' £ %^{V proce ss)> with (( e,s ), (E,s')) £ R p it holds true that E, 

s ' € d Vpmcess ({e,s}). 

Definition 17 (Atomic Attacker Process). An (atomic) attacker process for a set of sender addresses A C IPs is an 

atomic DY process p = ( I,Z,R,sq ) such that for all events e, and s £ we have that ((e,s), ( E,s ')) £ R iff s' = ( e,E,s ) 
and E = ({a 1 ,fi,m 1 ),...,(a n ,f„,m n )) with n £ N, a u ... ,a n £ IPs, f 0 , ...,/„ £ A, m u ...,m„ £ d Vpwcess ({e,s}). 

A.2 Scripting Processes 

We define scripting processes, which model client-side scripting technologies, such as JavaScript. Scripting processes 
are defined similarly to DY processes. 

Definition 18 (Placeholders for Scripting Processes). By V SC ript == {Ai,...} we denote an infinite set of variables 
used in scripting processes. 

Definition 19 (Scripting Processes). A scripting process (or simply, a script) is a relation R C x ‘Ty- ( V scnp ,) such 

that for all s £ s' G script) with ( s,s') £ R it follows that s' £ dy scrjpl (s). 

A script is called by the browser which provides it with state information (such as the script’s last state and limited 
information about the browser’s state) s. The script then outputs a term s', which represents the new internal state and 
some command which is interpreted by the browser. The term s' may contain variables Ai,... which the browser will 
replace by (otherwise unused) placeholders u \,... which will be replaced by nonces once the browser DY process 
finishes (effectively providing the script with a way to get “fresh” nonces). 

Similarly to an attacker process, we define the attacker script R 1 ": 

Definition 20 (Attacker Script). The attacker script R a " outputs everything that is derivable from the input, i.e., 
R a " = {(V) I s G l^s' £ dv scrip ,(s)}. 

A.3 Web System 

The web infrastructure and web applications are formalized by what is called a web system. A web system contains, 
among others, a (possibly infinite) set of DY processes, modeling web browsers, web servers, DNS servers, and 
attackers (which may corrupt other entities, such as browsers). 

Definition 21. A web system “WS = (Tfi’,5, script, .E 0 ) is a tuple with its components defined as follows: 

The first component, Tf, denotes a system (a set ofDY processes) and is partitioned into the sets Hon, Web, and 
Net of honest, web attacker, and network attacker processes, respectively. 

Every p £ Web U Net is an attacker process for some set of sender addresses AC IPs. For a web attacker p £ Web, 
we require its set of addresses I p to be disjoint from the set of addresses of all other web attackers and honest processes, 
i.e., I p ni p = % for all p' £ Hon U Web. Hence, a web attacker cannot listen to traffic intended for other processes. 
Also, we require that A = I p , i.e., a web attacker can only use sender addresses it owns. Conversely, a network attacker 
may listen to all addresses (i.e., no restrictions on I p ) and may spoof all addresses (i.e., the set A may be IPs). 

Every p £ Hon is a DY process which models either a web server, a web browser, or a DNS server, as further 
described in the following subsections. Just as for web attackers, we require that p does not spoof sender addresses 
and that its set of addresses I p is disjoint from those of other honest processes and the web attackers. 

The second component, S, is a finite set of scripts such that R“" £ S. The third component, script, is an injective 
mapping from S to S, i.e., by script every s £ S is assigned its string representation script(s). 

Finally, E° is an (infinite) sequence of events, containing an infinite number of events of the form (a, a, TRIGGER) 
for every a £ [j pe ^I p . 

A run of JfS is a run of initiated by E°. 
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B Message and Data Formats 


We now provide some more details about data and message formats that are needed for the formal treatment of the web 
model and the analysis of BrowserlD presented in the rest of the appendix. 

B.l Notations 

Definition 22 (Sequence Notations). For a sequence t = (t\,...,t n ) and a set s we use t G'' 1 s to say that t \.... ,t„ £ s. 
We define xgO t <$=>• 3/ : t;=x. We write t y to denote the sequence (t\,...,t n ,y). For a finite set M with 
M = {mi,... ,m„} we use ( M) to denote the term of the form (m\,... ,m n ). (The order of the elements does not matter; 
one is chosen arbitrarily.) 

Definition 23. A dictionary over X and Y is a term of the form 

((k u vi),...,(k n ,v n )) 

where k\,...,k n £ X, Vi,..., v n £ Y, and the keys k \,... ,k n are unique, i.e., Vi j : kj kj. We call every term ( ki,Vj), 
i£ {1,... ,n}, an element of the dictionary with key ki and value v,-. We often write [k\ : vi v,-,..., k n : v„] instead 

of ((k , ( k n ,v n }). We denote the set of all dictionaries overX and Y by [X x 7]. 

We note that the empty dictionary is equivalent to the empty sequence, i.e., [] = (). Figure 5 shows the short no¬ 
tation for dictionary operations that will be used when describing the browser atomic process. For a dictionary 
z = [k\ : v\,ki : V 2 ,... ,k n : v„] we write k £ z to say that there exists i such that k = ki. We write z[kj] := vj to ex¬ 
tract elements. If k qL z, we set z\k\ := (). 


[k\ : vi ,...,ki :vj,...,k„: v„] [kj] = v,- 
[ki :vi,...,kt-i : v,_i ,k t : v t ,k i+ i : v i+ i ...,k n : v„\-ki = 
[£i : :v,-_!,*,•+! :v i+ i ...,k n : v„] 


( 6 ) 


(V) 


Fig. 5. Dictionary operators with 1 < i < n. 


Given a term t = (t i,... ,t„), we can refer to any subterm using a sequence of integers. The subterm is determined 
by repeated application of the projection 7r ( - for the integers i in the sequence. We call such a sequence a pointer: 

Definition 24. A pointer is a sequence of non-negative integers. We write T.pfor the application of the pointer p to the 
term r. This operator is applied from left to right. For pointers consisting of a single integer, we may omit the sequence 
braces for brevity. 

Example 3. For the term r = (a.h. (c.d. (e. f))) and the pointer ~p = (3,1), the subterm of r at the position ~p is 
c = 7Ti(7T3 (t)). Also, t. 3.(3,1) = T.3.p = t.3.3.1 = e. 

To improve readability, we try to avoid writing, e.g., o. 2 or 772 ( 0 ) in this document. Instead, we will use the names 
of the components of a sequence that is of a defined form as pointers that point to the corresponding subterms. E.g., if 
an Origin term is defined as (host,protocol) and o is an Origin term, then we can write o. protocol instead of 772 ( 0 ) 
or o.2. See also Example 4. 

B.2 URLs 

Definition 25. A URL is a term of the form (URL, protocol, host,path,parameters) with protocol £ {P,S} (for plain 
(HTTP) and secure (HTTPS)), host £ Doms, path £ S and parameters £ [S x The set of all valid URLs is URLs. 

Example 4. For the URL u = (URL, a, b,c,d), ((.protocol = a. If, in the algorithm described later, we say ((.path := e 
then u = (URL ,a,b,c,e) afterwards. 
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B.3 Origins 

Definition 26. An origin is a term of the form (host,protocol) with host £ Doms and protocol £ {P, S}. We write 
Origins for the set of all origins. 

Example 5. For example, (F00,S) is the HTTPS origin for the domain F00, while (BAR,P) is the HTTP origin for the 
domain BAR. 

B.4 Cookies 

Definition 27. A cookie is a term of the form (name, content) where name £ ‘T^r, and content is a term of the form 
(value, secure, session,httpOnly) where value £ T^, secure, session, httpOnly £ {T,_L}. We write Cookies for the set 
of all cookies and Cookies"/or the set of all cookies where names and values are defined over ‘T^/fV). 

If the secure attribute of a cookie is set, the browser will not transfer this cookie over unencrypted HTTP connections. 
If the session flag is set, this cookie will be deleted as soon as the browser is closed. The httpOnly attribute controls 
whether JavaScript has access to this cookie. 

Note that cookies of the form described here are only contained in HTTP(S) requests. In responses, only the 
components name and value are transferred as a pairing of the form (name, value). 

B.5 HTTP Messages 

Definition 28. An HTTP request is a term of the form shown in (8). An HTTP response is a term of the form shown in 
(9). 

(HTTPReq, nonce, method, host, path, parameters, headers, body) (8) 

(HTTPResp, nonce, status, headers,body) (9) 

The components are defined as follows: 

• nonce £ serves to map each response to the corresponding request 

• method £ Methods is one of the HTTP methods. 

• host £ Doms is the host name in the HOST header of HTTP/1.1. 

• path £ § is a string indicating the requested resource at the server side 

• status £ S is the HTTP status code (i.e., a number between 100 and 505, as defined by the HTTP standard) 

• parameters £ [S X 'Z^] contains URL parameters 

• headers £ [S x containing request/response headers. The dictionary elements are terms of one of the follow¬ 
ing forms: 

• (Origin, o) where o is an origin 

• (Set-Cookie, c) where c is a sequence of cookies 

• (Cookie, c) where c £ [S x “2^] (note that in this header, only names and values of cookies are transferred) 

• (Location,/} where l £ URLs 

• (Referer,r) where r £ URLs 

• (Strict-Transport-Security, T) 

• body £ in requests and responses. 

We write HTTP Requests/HTTP Responses/or the set of all HTTP requests or responses, respectively. 

Example 6 (HTTP Request and Response). 

r :=(HTTPReq,/q ,P0ST, example.com, /show, ((index, 1)), 

[Origin: (example.com,S)], (foo,bar)) (10) 

s :=(HTTPResp,«i, 200, ((Set-Cookie, ((SID, (n 2 ,-L,_L, T))))), (some script,*)) (11) 

An HTTP GET request for the URL http: //example . com/show?index=l is shown in (10), with an Origin header 
and a body that contains (foo,bar). A possible response is shown in (11), which contains an httpOnly cookie with 
name SID and value «2 as well as the string representation somescript of the scripting process script -1 (somescript) 
(which should be an element of S) and its initial state x. 
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Encrypted HTTP Messages. For HTTPS, requests are encrypted using the public key of the server. Such a request 
contains an (ephemeral) symmetric key chosen by the client that issued the request. The server is supported to encrypt 
the response using the symmetric key. 

Definition 29. An encrypted HTTP request is of the form enc a ((in, k r ) ,k), where k, k! £ Of and m £ HTTPRequests. 
The corresponding encrypted HTTP response would be of the form enc s (m',k'), where m! £ HTTPResponses. We call 
the sets of all encrypted HTTP requests and responses HTTPSRequests or HTTPSResponses, respectively. 

Example 7. 


er\c 3 ((r,k }, pub(k exam pi e .com)) (12) 

en c s (s,k') (13) 

The term (12) shows an encrypted request (with r as in (10)). It is encrypted using the public key pub(k examp i e com ). 
The term (13) is a response (with s as in (11)). It is encrypted symmetrically using the (symmetric) key k! that was sent 
in the request (12). 

B.6 DNS Messages 

Definition 30. A DNS request is a term of the form (DNSResolve, domain,n) where domain £ Doms, n £ We call 
the set of all DNS requests DNS Requests. 

Definition 31. A DNS response is a term of the form (DNSResolved , domain, result,n) with domain £ Doms, result £ 
IPs, n £ We call the set of all DNS responses DNSResponses. 

DNS servers are supposed to include the nonce they received in a DNS request in the DNS response that they send 
back so that the party which issued the request can match it with the request. 

B.7 DNS Servers 

Here, we consider a flat DNS model in which DNS queries are answered directly by one DNS server and always 
with the same address for a domain. A full (hierarchical) DNS system with recursive DNS resolution, DNS caches, 
etc. could also be modeled to cover certain attacks on the DNS system itself. 

Definition 32. A DNS server d (in aflat DNS model) is modeled in a straightforward way as an atomic DY process 
(I d , {sq},/^,Sq). It has a finite set of addresses I d and its initial (and only) state Sq encodes a mapping from domain 
names to addresses of the form 

Sq = ((domaini,ai), (domains, af ),...) . 

DNS queries are answered according to this table (otherwise ignored). 


C Detailed Description of the Browser Model 

Following the informal description of the browser model in Section 3.3, we now present a formal model. We start by 
introducing some notation and terminology. 

C.l Notation and Terminology (Web Browser State) 

Before we can define the state of a web browser, we first have to define windows and documents. 

Definition 33. A window is a term of the form w = (nonce.documents, opener) with nonce £ documents (N' 
Documents (defined below), opener £ 9f\J {_L} where d. active = T for exactly one d £^ documents if documents 
is not empty (we then call d the active document of w). We write Windows for the set of all windows. We write 
w.activedocument to denote the active document inside window w if it exists and () else. 
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We will refer to the window nonce as (window) reference. 

The documents contained in a window term to the left of the active document are the previously viewed documents 
(available to the user via the “back” button) and the documents in the window term to the right of the currently active 
document are documents available via the “forward” button. 

A window a may have opened a top-level window b (i.e., a window term which is not a subterm of a document 
term). In this case, the opener part of the term b is the nonce of a, i.e., Z.opener = a.nonce. 

Definition 34. A document d is a term of the form 

(nonce, location, referrer, script, scriptstate, scriptinputs, subwindows, active) 

where nonce £ location £ URLs, referrer £ URLsU{_L}, script £ scriptstate £ F^, scriptinputs £ F^, 
subwindows Windows, active £ {T,_L}. A limited document is a term of the form (nonce,subwindows) with 
nonce, subwindows as above. A window w £§ subwindows is called a subwindow (of d). We write Documents/or the 
set of all documents. For a document term d we write d. origin to denote the origin of the document, i.e., the term 
(d. location.host,r/.location,protocol) £ Origins. 

We will refer to the document nonce as (document) reference. 

We can now define the set of states of web browsers. Note that we use the dictionary notation that we introduced in 
Definition 23. 

Definition 35. The set of states Z p of a web browser atomic process p consists of the terms of the form 

(windows, ids, secrets, cookies, localStorage, sessionStorage, keyMapping, 
sts, DNSaddress, pendingDNS ,pendingRequests, isCorrupted) 


where 

• windows Windows, 

• ids £'■' 

• secrets £ [Origins x AQ, 

• cookies is a dictionary over Doms and dictionaries of Cookies, 

• localStorage £ [Origins x 

• sessionStorage £ \OR x F^J for OR := {(o,r)\o £ Origins, r £ 9{}, 

• keyMapping £ [Doms x %i\, 

• sts Doms, 

• DNSaddress £ I Ps, 

• pendingDNS £ x F^ ], 

• pendingRequests £ F^, 

• and isCorrupted £ {_L,FULLCORRUPT, CLOSECORRUPT}. 

Definition 36. For two window terms w and w 1 we write w ch,,do w > if 

w £^ wCactivedocument.subwindows . 

We write ch --° —> for the transitive closure. 

In the following description of the web browser relation R p we will use the helper functions Subwindows, Docs, 
Clean, CookieMerge and AddCookie. 

Given a browser state s, Subwindows(.s) denotes the set of all pointers 16 to windows in the window list s. windows, 
their active documents, and (recursively) the subwindows of these documents. We exclude subwindows of inactive 
documents and their subwindows. With Docs(s) we denote the set of pointers to all active documents in the set of 
windows referenced by Subwindows(s). 

16 Recall the definition of a pointer in Definition 24. 
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Definition 37. For a browser state s we denote by Subwindows(i) the minimal set of pointers that satisfies the fol¬ 
lowing conditions: (1) For all windows w G® s. windows there is a p G Subwindows(s) such that s.p = w. (2) For 
all p G Subwindows(s), the active document d of the window s.p and every subwindow w of d there is a pointer 
p' G Subwindows(s) such that s.p' = w. 

Given a browser state s, the set Docs(s) of pointers to active documents is the minimal set such that for every 
p G Subwindows(s), there is a pointer p 1 G Docs(s) with s.p’ = s./?.activedocument. 

By Subwindows + (s) and Docs + (s) we denote the respective sets that also include the inactive documents and their 
sub windows. 

The function Clean will be used to determine which information about windows and documents the script running 
in the document d has access to. 

Definition 38. Let s be a browser state and d a document. By Clean(s,<f) we denote the term that equals s. windows but 
with all inactive documents removed (including their subwindows etc.) and all subterms that represent non-same-origin 
documents w.r.t. d replaced by a limited document d 1 with the same nonce and the same subwindow list. Note that 
non-same-origin documents on all levels are replaced by their corresponding limited document. 

The function CookieMerge merges two sequences of cookies together: When used in the browser, oldcookies is the 
sequence of existing cookies for some origin, newcookies is a sequence of new cookies that was output by some script. 
The sequences are merged into a set of cookies using an algorithm that is based on the Storage Mechanism algorithm 
described in RFC6265. 

Definition 39. For a sequence of cookies (with pairwise different names) oldcookies and a sequence of cookies 
newcookies, the set CookieMerg e(oldcookies,newcookies) is defined by the following algorithm: From newcookies 
remove all cookies c that have c. content.httpOnly = T. For any c, c’ G® newcookies, c.name = cCname, remove 
the cookie that appears left of the other in newcookies. Let m be the set of cookies that have a name that either 
appears in oldcookies or in newcookies, but not in both. For all pairs of cookies ( c 0 id,Cnew ) with c 0 id G^ oldcookies, 
c„ew newcookies, c 0 ij. name = c new . name, add c new to m ifc 0 ij. content. httpOnly = _L and add c 0 id to m otherwise. 
The result of Cook\eMerge(oldcookies,newcookies) is m. 

The function AddCookie adds a cookie c received in an HTTP response to the sequence of cookies contained in the 
sequence oldcookies. It is again based on the algorithm described in RFC6265 but simplified for the use in the browser 
model. 


Definition 40. For a sequence of cookies (with pairwise different names) oldcookies and a cookie c, the sequence 
AddCooki e(oldcookies,c) is defined by the following algorithm: Let m := oldcookies. Remove any c’ from m that has 
c.name = c , .name. Append c to m and return m. 

The function NavigableWindows returns a set of windows that a document is allowed to navigate. We closely 
follow [15], Section 5.1.4 for this definition. 

Definition 41. The set NavigableWindows^js') is the set W C Subwindows(s') of pointers to windows that the active 
document in w is allowed to navigate. The setW is defined to be the minimal set such that for every w 1 G Subwindows(s / ) 
the following is true: 

• //V.w'.activedocument.origin = s'.vv.activedocument.origin (i.e., the active documents in w and w 1 are 
same-origin), then w’ G W, and 

• If s' .w cl . 1,ldo f‘y s > mW r ^ yf' g Subwindows(s / ) with s' .w' cl fi lclo f > f .w" (w' is a top-level window and w is an 
ancestor window ofw'), then w' G W, and 

• If 3p G Subwindows(i') such that s'.vv' cMdo C \ s ' p 

A s'. p.activedocument.origin = s'. vv.activedocument.origin (w' is not a top-level window but there is an 
ancestor window p ofw' with an active document that has the same origin as the active document in w), then 
w' G W, and 

• If 3p G Subwindows(s / ) such that s' .w'. opener = s'.p. nonce A p GW (w' is a top-level window—it has an 
opener—and w is allowed to navigate the opener window ofw', p), then w' G W. 
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C.2 Description of the Web Browser Atomic Process 

We will now describe the relation R p of a standard HTTP browser p. We define (((( a,f,m)),s ), (M.s')) to belong to 
R p iff the non-deterministic algorithm presented below, when given (( a,f,m),s) as input, terminates with stop M, s', 
i.e., with output M and s'. Recall that ( a,f,m ) is an (input) event and s is a (browser) state, M is a sequence of (output) 
protoevents, and s' is a new (browser) state (potentially with placeholders for nonces). 

Notations. The notation let n <— N is used to describe that n is chosen non-deterministically from the set N. We write 
for each s £ M do to denote that the following commands (until end for) are repeated for every element in M, where 
the variable s is the current element. The order in which the elements are processed is chosen non-deterministically. 
We will write, for example, 

let x,y such that (Constant, x,y) = t if possible; otherwise doSomethingElse 
for some variables x,y, a string Constant, and some term t to express that x := tti{t), and y := itj,{t) if Constant = 
7ri (t) and if | (Constant, x,y) \ = |f |, and that otherwise x and y are not set and doSomethingElse is executed. 
Placeholders. In several places throughout the algorithms presented next we use placeholders to generate “fresh” 
nonces as described in our communication model (see Definition 3). Figure 6 shows a list of all placeholders used. 


Placeholder 

Usage 

v\ 

Algorithm 7, new window nonces 

vi 

Algorithm 7, new HTTP request nonce 


Algorithm 7, lookup key for pending HTTP requests entry 

V A 

Algorithm 5, new HTTP request nonce (multiple lines) 

v5 

Algorithm 5, new subwindow nonce 

V(, 

Algorithm 6, new HTTP request nonce 

V 1 

Algorithm 6, new document nonce 

OJ 

Algorithm 4, lookup key for pending DNS entry 

ag 

Algorithm 1, new window nonce 

a w ,... 

Algorithm 5, replacement for placeholders in scripting process output 


Fig. 6. List of placeholders used in browser algorithms. 


Before we describe the main browser algorithm, we first define some functions. 

Functions. In the description of the following functions we use a, f, m, and s as read-only global input variables. All 
other variables are local variables or arguments. 

The following function, GETNAVIGABLEWINDOW, is called by the browser to determine the window that is 
actually navigated when a script in the window s',w provides a window reference for navigation (e.g., for opening a 
link). When it is given a window reference (nonce) window, GETNAVIGABLEWINDOW returns a pointer to a selected 
window term in s': 

• If window is the string _BLANK, a new window is created and a pointer to that window is returned. 

• If window is a nonce (reference) and there is a window term with a reference of that value in the windows in s', a 
pointer w' to that window term is returned, as long as the window is navigable by the current window’s document 
(as defined by NavigableWindows above). 

In all other cases, vv is returned instead (the script navigates its own window). 


Algorithm 1 Determine window for navigation. 

1: function GETNAVIGABLEWINDOWtw, window, noreferrer, s') 

2: if window = _BLANK then > Open a new window when _BLANK is used 

3: if noreferrer = T then 

4: let w' := {vg, (), s', w.nonce) 

5: else 
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6: let w' := (i/g, (),_!_} 

7: end if 

8: let s'.windows := s',windows +0 w' and let W 1 be a pointer to this new element in s' 

9: return w' 

10: end if 

11: let vv' NavigableWindows(vv,s') such that s'.w 1 . nonce = window if possible; otherwise return W 

12: return w' 

13: end function 

The following function takes a window reference as input and returns a pointer to a window as above, but it checks 
only that the active documents in both windows are same-origin. It creates no new windows. 


Algorithm 2 Determine same-origin window. 

1: function GETWINDOWCw, window, s') 

2: let w' Subwindows (s') such that s'.vv'.nonce = window if possible; otherwise return w 

3: if s'.w'. activedocument.origin = s'.w.activedocument.origin then 

4: return w' 

5: end if 

6: return w 

7: end function 

The next function is used to stop any pending requests for a specific window. From the pending requests and pending 
DNS requests it removes any requests with the given window reference n. 


Algorithm 3 Cancel pending requests for given window. 

1: function CANCELNAV(«, s') 

2: remove all (n,req,key,f) from s'.pendingRequests for any req, key,f 

3: remove all (x, {n,message,protocol}) from s'.pendingDNS for any.r, message, protocol 

4: return s' 

5: end function 

The following function takes an HTTP request message as input, adds cookie and origin headers to the message, 
creates a DNS request for the hostname given in the request and stores the request in s'.pendingDNS until the DNS 
resolution finishes. For normal HTTP requests, reference is a window reference. For XHRs, reference is a value of the 
form (document , nonce) where document is a document reference and nonce is some nonce that was chosen by the 
script that initiated the request, protocol is either P or S. origin is the origin header value that is to be added to the 
HTTP request. 


Algorithm 4 Prepare headers, do DNS resolution, save message. 

1: function SEND (reference, message, protocol, origin, refer rer, s') 

2 : if message. host G® s'.sts then 

3: let protocol := S 

4: end if 

5: let cookies := ({(c.name, c. content.value)|c 6^ s '.cookies [message. host] 

A (c.content.secure => (protocol = S))}} 

6: let message.headers [Cookie] := cookies 

1: if origin f then 

8: let message .headers [Origin] := origin 

9: end if 

10: if referrer f T then 

11: let message. headers[Ref erer] := referrer 

12: end if 

13: let i / .pendingDNS[r'8] := (reference,message,protocol) 

14: stop ((^'.DNSaddress,a, {DNSResolve,/7r«t,n}}), s' 

15: end function 
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The function RUNSCRIPT performs a script execution step of the script in the document s'.d (which is part of the 
window s' .w). A new script and document state is chosen according to the relation defined by the script and the new 
script and document state is saved. Afterwards, the command that the script issued is interpreted. 


Algorithm 5 Execute a script. 

1: function RUNSCRIPT(vv, d. s') 

2: let tree := Clean)/, s'.d) 

3: let cookies := ({(c.name, c. content.value)|c 6® /.cookies [/./.origin.host] 

A c. content.httpOnly = _L 

A (c.content.secure => (/./.origin.protocol = S))}) 

4: let tlw <— / .windows such that tlw is the top-level window containing d 

5: let sessionStorage := /.sessionStorage [ (s'.d. origin, Zw.nonce)] 

6: let loccilStorage := /.localStorage [/./.origin] 

7: let secret := /.secrets [/./.origin] 

8: let R «— script” 1 )/./, script) 

9: let in = {tree, /./.nonce,/./.scriptstate, /./.scriptinputs, cookies, localStorage, sessionStorage, /.ids, secret } 

10 : let state 1 <— T^V), 

•—> cookie s' <— Cookies 17 , 
localStorage 1 <— 
sessionStorage' 1 X-(V), 

command 'ZX(V), 

out* := {state', cookie /, localStorage', sessionStorage', command) 
such that (in, out*) £ ft 
11 : let out := out x [v w /\i,v n /\ 2 ,...] 

12: let /.cookies [././.origin.host] := (CookieMerge(/.cookies [/./.origin.host], cookies' )} 

13: let /.localStorage [/./.origin] := localStorage' 

14: let /.sessionStorage [(/./.origin,/w.nonce)] := sessionStorage' 

15: let /./.scriptstate := state' 

16: switch command do 

17: case (HREF, url,hrefwindow,noreferrer) 

18: let w' := GETNAVIGABLEWII\IDOW(w, hrefwindow, noreferrer, /) 

19: let req := (HTTPReq, 04 , GET, url.host, nr/.path, {),url. parameters, ()) 

20: if noreferrer = X then 

21: let referrer := /./.location 

22: else 

23: let referrer := _L 

24: end if 

25: let / := CAI\ICELNAV(/.w/.nonce,/) 

26: SEND(/.v/.nonce, req, w?7.protocol, X, referrer, s') 

27: case (IFRAME , url, window) 

28 : letv/ := GETWINDOW(w,n , z>zZovr,/) 

29: let req := (HTTPReq, U 4 , GET, url.host, url.path, {),url. parameters, ()) 

30: let referrer := /.v/.activedocument.location 

31: let w':= (1/5,0,X) 

32: let /. w'. act i vedocument.subwindows := /.wAactivedocument.subwindows +0 w' 

33: SEND(i/ 5, req, zzr/.protocol, X, referrer, s') 

34: case {FORM,url,method,data,hrefwindow) 

35: if method {GET, POST} then 17 

36: stop (), / 

37: end if 

38: let w' := GETNAVIGABLEWII\IDOW(vr, hrefwindow, X, /) 


17 The working draft for HTML5 allowed for DELETE and PUT methods in HTML5 forms. However, these have since been 
removed. See http: //www. w3. org/TR/2010/WD-html5-diff-20101019/#changes-2010-06-24. 
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if method = GET then 

let body := () 

let parameters := data 

let origin := _L 

else 

let body := data 

let parameters := url. parameters 
let origin := s'.d. origin 

end if 

let req := (HTTPReq, U 4 , method, url. host, url. path, (), parameters, body) 

let referrer := s'.d. location 

let s' := CANCELNAV(s'.w' .nonce, s’) 

SEN D(s'.vv'.nonce, req, Mr/.protocol, origin, referrer, s') 
case (SETSCRIPT .window,script) 

let w' := GETWINDOW(w,H’z>zrfovv,s') 
let s' .w'.activedocument.script := script 
stop (}, s' 

case (SETSCRIPTSTATE, wzVi<7oH’,.scn/?Mflfe} 
let w' := GETWINDOW^wznrfovAs') 
let s' .w'.activedocument.scriptstate := scriptstate 
stop () , s' 

case (XVlUmPREQVEST, url, method, data, xhrreference) 

if method £ {CONNECT. TRACE, TRACK} A xhrreference £ {df, X} then 
stop (}, s' 
end if 

if izr/.host ^ s'.d. origin.host V url. protocol ^ s'.r/.origin.protocol then 
stop (), s' 
end if 

if method £ {GET, HEAD} then 
let data := {} 
let origin := _L 

else 

let origin := s'.d .origin 

end if 

let req := (HTTPReq, U 4 ,method, url. host, ur/.path,, Mr/.parameters, data) 
let referrer := s'.d .location 

SEND((/.<7.nonce, xhrreference), req, wr/.protocol, origin, referrer, s') 
case (BACK, window) 18 

let w 1 := GETNAVIGABLEV\/[NDOW(w, window, _L, s') 
if 3} G N, j > 1 such that s',\v'. documents.active = T then 
let s'.w'. documents. j .active := _L 
let s'.w'. documents .(j — 1).active := T 
lets' := CANCELNAV(s'.w'.nonce,s') 
end if 
stop (), s' 

case (FORWARD, window) 

let w' := GETNAVIGABLEWINDOW(w, window, _L, s') 

if 3} £ N such that s'.w'. documents.}.active = T A s'.w'. documents. (j+ 1) £ Documents then 
let s'.w'. documents. j .active := ± 
let s'.w'. documents .(j + 1).active := T 
lets' := CANCELNAV(s'.w'.nonce,s') 


18 Note that navigating a window using the back/forward buttons does not trigger a reload of the affected documents. While real 
world browser may chose to refresh a document in this case, we assume that the complete state of a previously viewed document is 
restored. A reload can be triggered non-deterministically at any point (in the main algorithm). 
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90: end if 

91: stop (},•?' 

92: case (CLOSE, window) 

93: let w' := GETNAVIGABLEWINDOW(W, window, _L, s') 

94: remove s',w' from the sequence containing it 

95: stop(),i' 

96: case (POSTMESSAGE, window,message, origin) 

97: let w' <— Subwindows(s') such that s'.w 1 . nonce = window 

98: if 3j £ N such that s'.w'. documents, j. active = T 

°4 A (original. => s'. vP.documents.}. origin = origin) then 
99: let s'.w'. documents, j. scriptinputs 

°4 := s'.w'. documents, j. scriptinputs 

< -4 +0 (POSTMESSAGE,v'.vv.nonce,j'.d.origin, message) 

100: end if 

101: stop(),i' 

102 : case else 

103: stop (}, s' 

104: end function 

The function PROCESSRESPONSE is responsible for processing an HTTP response (response) that was received 
as the response to a request ( request ) that was sent earlier. In reference, either a window or a document reference is 
given (see explanation for Algorithm 4 above). Again, protocol is either P or S. 

The function first saves any cookies that were contained in the response to the browser state, then checks whether 
a redirection is requested (Location header). If that is not the case, the function creates a new document (for normal 
requests) or delivers the contents of the response to the respective receiver (for XHR responses). 


Algorithm 6 Process an HTTP response. 

1: function PROCESSRESPONSEOe.spoH.se, reference, request,protocol, s') 

2: if Set-Cookie £ response. headers then 

3: for each c £^ response.headers [Set-Cookie], c £ Cookies do 

4: let /.cookies [request.nrl. host] := AddCookie]/. cookies [regMe.yf.url.host] ,c) 

5: end for 

6: end if 

7: if Strict-Transport-Security £ response. headers A protocol = S then 

8 : let s' .sts := /.sts +V request.host 

9: end if 

10: if Referer £ request. headers then 

11: let referrer := mpresf .headers [Ref erer] 

12: else 

13: let referrer := _L 

14: end if 

15: if Location £ response. headers A response. status £ {303,307} then 19 

16: let url := response. headers [Location] 

17: let method' := request. method 211 

18: let body 1 := request. body 21 


19 The RFC for HTTPbis (currently in draft status), which obsoletes RFC 2616, does not specify whether a POST/DELETE/etc. 
request that was answered with a status code of 301 or 302 should be rewritten to a GET request or not (“for historic reasons” that 
are detailed in Section 7.4.). As the specification is clear for the status codes 303 and 307 (and most browsers actually follow the 
specification in this regard), we focus on modeling these. 

20 While the standard demands that users confirm redirections of non-safe-methods (e.g., POST), we assume that users generally 
confirm these redirections. 

21 If, for example, a GET request is redirected and the original request contained a body, this body is preserved, as HTTP allows 
for payloads in messages with all HTTP methods, except for the TRACE method (a detail which we omit). Browsers will usually 
not send body payloads for methods that do not specify semantics for such data in the first place. 
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19: if Origin e request .headers then 

20: let origin := (request.headers[Origin],(request.host,protocol}} 

21: else 

22: let origin := ± 

23: end if 

24: if response. status = 303 A request. method ^ {GET, HEAD} then 

25: let method' := GET 

26: let body':= () 

27: end if 

28: if $ w £ Subwindows(s') such that s'.W.nonce = reference then [> Do not redirect XHRs. 

29: stop(),s 

30: end if 

31: let req := (HTTPReq, Uq,method',url. host, nr/.path, (), «r/.parameters, body'} 

32: SEND (reference, req, i«7.protocol, origin, referrer, s') 

33: end if 

34: if 3vv £ Subwindows(s') such that s'.w.nonce = reference then > normal response 

35: let location := {URL, protocol,request. host, request.paXh,request. parameters) 

36: if response .body (*, *) then 

37: stop {}, s' 

38: end if 

39: let script := it\(response. body) 

40: let scriptstate := ^(response, body) 

41: letrf := (z/7, location, referrer, script, scriptstate, (),(),T) 

42: if s'.W.documents = {} then 

43: let s' .w. documents := (d) 

44: else 

45: let i t— N such that i'.W.docnments.i.active = T 

46: let i'.w.documents.;'.active := J_ 

47: remove i , .vi'.docnments.(/+ 1) and all following documents from s'.w.documents 

48: let s' .w. documents := s'. w. documents +0 d 

49: end if 

50: stop {}, s' 

51: else if 3 w e Subwindows(s'), d such that s'. d. nonce = it\(reference) 

> A s'.d = s'.w.activedocument then > process XHR response 

52: let s'.rf.scriptinputs := s'.rf.scriptinputs +0 (XMLHTTPREQUEST, response. body, ^(reference)) 

53: end if 

54: end function 

Main Algorithm. This is the main algorithm of the browser relation. It receives the message m as input, as well as a, 
f and s as above. 

Algorithm 7 Main Algorithm 

Input: ( a,f,m),s 
1: let s' := s 

2: if s.isCorrupted ^ A then 

3: let s'.pendingRequests := (m,s.pendingRequests) > Collect incoming messages 

4: let m' t— dy (s') 

5: let a' t— IPs 

6 : stop ((a',a,m'}}, s' 

7: end if 

8 : if in = TRIGGER then > A special trigger message. 

9: let switch t— {1,2,3} 

10: if switch = 1 then > Run some script. 

11 : let w <— Subwindows(s') such that s'.vv.documents f (} if possible; otherwise stop (), s' 

12 : let d := activedocument 

13: RUNSCRIPT(w, d, s') 
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> Create some new request. 


14: else if switch = 2 then 

15: let w' (iq, (},T) 

16: let s'.windows := s',windows +« w' 

17: let protocol A- {P, S} 

18: let host a- Doms 

19: let path a- § 

20: let parameters A- [S x S] 

21: let req := (HTTPReq, V 2 ,GET,host,path, {),parameters, ()) 

22: SEND(iq, req, protocol, _L, s') 

23: else if switch = 3 then > Reload some document. 

24: let w a- Subwindows(s') such that s'.w.documents {) if possible; otherwise stop (), s' 

25: let url := s'.rv.activedocument.location 

26: let req := (HTTPReq, i-q,GET, w/.host, «/7.path, (),url. parameters, ()} 

27: let referrer := s'.w.activedocument.ref errer 

28: lets' := CANCELNAV(s'.w.nonce,s') 

29: SEND(s'.vv.nonce, req, wr/.protocol, ±, referrer, s') 

30: end if 

31: else if m = FULLCORRUPT then t> Request to corrupt browser 

32: let s'.isCorrupted := FULLCORRUPT 

33: stop (},s' 

34: else if m = CL0SEC0RRUPT then > Close the browser 

35: let s'. secrets := (} 

36: let s'. windows := (} 

37: let s'.pendingDNS := (} 

38: let s'.pendingRequests := () 

39: let s'.sessionStorage := () 

40: let s'.cookies Cookies such that (c G® s'.cookies) -<=> (c G® s.cookies Ac.content.session = _L) 

41: let s'.isCorrupted := CL0SEC0RRUPT 

42: stop (), s' 

43: else if 3 {reference, request, key,f) G” s'.pendingRequests 

such that 7 ri (dec s (m, key)) = HTTPResp then > Encrypted HTTP response 

44: let in' := dec s (m,key) 

45: if in' .nonce ^ request. nonce then 

46: stop(),s 

47: end if 

48: remove {reference, request,key ,/) from s'.pendingRequests 

49: PROCESSRESPONSE(m', reference, request, S, s') 

50: else if -k\ (m) = HTTPResp A 3 {reference, request,A-,f) G® s'.pendingRequests such that in', nonce = request.key then 
51: remove {reference, request, -L,/) from s'.pendingRequests 

52: PROCESSRESPONSE(m, reference, request, P, s') 

53: else if m G DNSResponses then > Successful DNS response 

54: if m.nonce ^ s.pendingDNS V in. result ^ IPs V m. domain ^ 7T2(s.pendingDNS).host then 

55: stop(),s 

56: end if 

57: let {reference, message,protocol) := s.pendingDNS [m.nonce] 

58: if protocol = S then 

59: let s'.pendingRequests := s'.pendingRequests +0 {reference, message, v$, m. result) 

60: let message := enc a ((messagc,i'3),s'.keyMapping[7Mcssagc.host]) 

61: else 

62: let s'.pendingRequests := s'.pendingRequests +0 {reference, message, _L, m. result) 

63: end if 

64: let s'.pendingDNS := s'.pendingDNS — m.nonce 

65: stop {{m. result, a,message)), s' 

66: end if 
67: stop (), s 
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D Formal Model of SPRESSO 


We here present the full details of our formal model of SPRESSO. For our analysis regarding our authentication and 
privacy properties below, we will further restrict this generic model to suit the setting of the respective analysis. 

We model SPRESSO as a web system (in the sense of Appendix A. 3). We call a web system SWS = 
script, E°) an SPRESSO web system if it is of the form described in what follows. 

D.l Outline 

The system ‘W = Hon U Web U Net consists of web attacker processes (in Web), network attacker processes (in 
Net), a finite set FWD of forwarders, a finite set B of web browsers, a finite set RP of web servers for the relying 
parties, a finite set I DP of web servers for the identity providers, and a finite set DNS of DNS servers, with Hon := 
BURPUlDPU FWDU DNS. More details on the processes in ‘W are provided below. Figure 7 shows the set of scripts 
S and their respective string representations that are defined by the mapping script. The set E° contains only the trigger 
events as specified in Appendix A.3. 


s G S 

script(s) 

r m 

att script 

script rp 

script rp 

script rp redir 

script rp redir 

script idp 

script idp 

scriptJwd 

script_fwd 


Fig. 7. List of scripts in S and their respective string representations. 


This outlines SWS- We will now define the DY processes in SWS and their addresses, domain names, and secrets in 
more detail. The scripts are defined in detail in Appendix D.16. 

D.2 Addresses and Domain Names 

The set IPs contains for every web attacker in Web, every network attacker in Net, every relying party in RP. every 
identity provider in IDP, every forwarder in FWD, every DNS server in DNS, and every browser in B a finite set of 
addresses each. By addr we denote the corresponding assignment from a process to its address. The set Doms contains 
a finite set of domains for every forwarder FWD, every relying party in RP, every identity provider in IDP, every web 
attacker in Web, and every network attacker in Net. Browsers (in B) and DNS servers (in DNS) do not have a domain. 
By addr and dom we denote the assignments from atomic processes to sets of IPs and Doms, respectively. 

D.3 Keys and Secrets 

The set 5\£ of nonces is partitioned into four sets, an infinite sequence N, an infinite set K^sl^ an infinite set K s { ga , and a 
finite set Secrets. We thus have 





U/fssLU^signU Secrets . 


infinite sequence finite finite finite 


The set N contains the nonces that are available for each DY process in ‘W (it can be used to create a run of W). 

The set A'ssl contains the keys that will be used for SSL encryption. Let sslkey: Doms —► Atssi. be an injective 
mapping that assigns a (different) private key to every domain. 

The set K s [ gn contains the keys that will be used by IdPs for signing IAs. Let signkey: IdPs —> K s i gn be an injective 
mapping that assigns a (different) private key to every identity provider. 

The set Secrets is the set of passwords (secrets) the browsers share with the identity providers. 
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D.4 Identities 


Indentites are email addresses, which consist of a user name and a domain part. For our model, this is defined as 
follows: 

Definition 42. An identity (email address) i is a term of the form {name,domain) with name £ § and domain £ Doms. 
Let ID be the finite set of identities. By ID' we denote the set {{name, domain) £ ID | domain £ dom(y)}. 

We say that an ID is governed by the DY process to which the domain of the ID belongs. Formally, we define the 
mapping governor: ID —>• C W, {name,domain) dom~ {domain). 

The governor of an ID will usually be an IdP, but could also be the attacker. 

By secretOfID : ID —► Secrets we denote the bijective mapping that assigns secrets to all identities. 

Let ownerOfSecret: Secrets —> B denote the mapping that assigns to each secret a browser that owns this secret. 
Now, we define the mapping ownerOfID : ID —>■ B, i i—>■ owner0f5ecret(secret0flD(/)), which assigns to each identity 
the browser that owns this identity (we say that the identity belongs to the browser). 

D.5 Tags and Identity Assertions 

Definition 43. A tag is a term of the form en c s ({o,n) ,k) for some domain d, a nonce n £ and a nonce (here used 
as a symmetric key) k. 

Definition 44. An identity assertion (IA) is a term of the form sig {{t,e,d'),k) for a tag t, an email address (identity) 
e, a domain d' and a nonce k. We call it an encrypted identity assertion (EIA) if it is additionally (symmmetrically) 
encrypted (i.e., it is of the form enc 5 {s,k') if s is an IA and k' is a nonce. 

D.6 Corruption 

RPs, IdPs and FWDs can become corrupted: If they receive the message CORRUPT, they start collecting all incoming 
messages in their state and (upon triggering) send out all messages that are derivable from their state and collected 
input messages, just like the attacker process. We say that an RP, an IdP or an forwarder is honest if the according part 
of their state (s. corrupt) is _L, and that they are corrupted otherwise. 

We are now ready to define the processes in Lf as well as the scripts in S in more detail. 

D.7 Processes in W (Overview) 

We first provide an overview of the processes in W. All processes in ‘W (except for DNS servers) contain in their 
initial states all public keys and the private keys of their respective domains (if any). We define I p = addr(/?) for all 
p £ Hon U Web. 

Web Attackers. Each wa £ Web is a web attacker (see Appendix A. 3), who uses only his own addresses for sending 
and listening. 

Network Attackers. Each na £ Net is a network attacker (see Appendix A. 3), who uses all addresses for sending and 
listening. 

Browsers. Each b £ B is a web browser as defined in Appendix C. The initial state contains all secrets owned by b, 
stored under the origin of the respective IdP. See Appendix D. 11 for details. 

Relying Parties. A relying party r £ RP is a web server. RP knows four distinct paths: /, where it serves the index web 
page (script_rp), /startLogin, where it only accepts POST requests and mainly issues a fresh RP nonce (details 
see below), /redir, where it only accepts requests with a valid login session token and serves script_rp_redir to 
redirect the browser to the IdP, and /login, where it also only accepts POST requests with login data obtained during 
the login process by script_rp running in the browser. It checks this data and, if the data is deemed “valid”, it issues 
a service token (again, for details, see below). The RP keeps a list of such tokens in its state. Intuitively, a client having 
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such a token can use the service of the RP (for a specific identity record along with the token). Just like IdPs, RPs can 
become corrupted. 

Identity Providers. Each IdP is a web server. As outlined in Section 2.1, users can authenticate to the IdP with their 
credentials. IdP tracks the state of the users with sessions. Authenticated users can receive IAs from the IdP. When 
receiving a special message (CORRUPT) IdPs can become corrupted. Similar to the definition of corruption for the 
browser, IdPs then start sending out all messages that are derivable from their state. 

Forwarders. FWDs are web servers that have only one state and only serve the script script_fwd. See Appendix D.14 
for details. 

DNS. Each dns £ DNS is a DNS server as defined in Appendix B.7. Their state contains the allocation of domain 
names to IP addresses. 

D.8 SSL Key Mapping 

Before we define the atomic DY processes in more detail, we first define the common data structure that holds the 
mapping of domain names to public SSL keys: For an atomic DY process p we define 

sslkeys p = ({(d 1 ss\key(d)} \ d £ dom(p)}). 


D.9 Web Attackers 

Each wa £ Web is a web attacker. The initial state of each wa is s^ 0 = ( attdoms ,sslkeys,signkeys ), where attdoms is a 
sequence of all domains along with the corresponding private keys owned by wa, sslkeys is a sequence of all domains 
and the corresponding public keys, and signkeys is a sequence containing all public signing keys for all IdPs. All other 
parties use the attacker as a DNS server. 


D.10 Network Attackers 

As mentioned, each network attacker na is modeled to be a network attacker as specified in Appendix A.3. 
We allow it to listen to/spoof all available IP addresses, and hence, define I na = IPs. The initial state is = 
(attdoms , sslkeys, signkeys) , where attdoms is a sequence of all domains along with the corresponding private keys 
owned by the attacker na, sslkeys is a sequence of all domains and the corresponding public keys, and signkeys is a 
sequence containing all public signing keys for all IdPs. 


D.ll Browsers 

Each b £ B is a web browser as defined in Appendix C, with I b := addr(/?) being its addresses. 

To define the inital state, first let ID b := ownerOfID -1 (b) be the set of all IDs of b, lD b d := {i \ 3x: i = (x,d) £ ID b } 
be the set of IDs of b for a domain d, and SecretDomains b := [d ID bd ^ 0} be the set of all domains that b owns 
identities for. 

Then, the initial state ,v[j is defined as follows: the key mapping maps every domain to its public (ssl) key, according 
to the mapping sslkey; the DNS address is addr(p) with p £ TP; the list of secrets contains an entry ((d, S ),s) for each 
d £ SecretDomains b and s = secretOflD(/) for some i £ lD hd (5 is the same for all /); ids is ( ID b ); sts is empty. 

D.12 Relying Parties 

A relying party r £ RP is a web server modeled as an atomic DY process (I r ,Z' ,R r ,Sq) with the addresses I r := addr(r). 
Its initial state s 0 contains its domains, the private keys associated with its domains, the DNS server address, and the 
domain name of a forwarder. The full state additionally contains the sets of service tokens and login session identifiers 
the RP has issued. RP only accepts HTTPS requests. 
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RP manages two kinds of sessions: The login sessions, which are only used during the login phase of a user, and the 
service sessions (we call the session identifier of a service session a service token). Service sessions allow a user to use 
RP’s services. The ultimate goal of a login flow is to establish such a service session. 

In a typical flow with one client, r will first receive an HTTP GET request for the path /. In this case, r returns the 
script script_rp (see below). 

After the user entered her email address, r will receive an HTTPS POST XMLHTTPRequest for the path 
/startLogin. In this request, it expects the email address the user entered. The relying party then contacts the 
user’s email provider to retrieve the SPRESSO support document (where it extracts the public key of the IdP). After 
that, r selects the nonces rpNonce, iaKey, tagKey, and loginSessionToken. It creates the tag as the (symmetric) encryp¬ 
tion of its own domain and the rpNonce with tagKey. It then returns to the browser the loginSessionToken, the tagKey, 
and the domain of the forwarder (S(r).FWDDomain). 

When the RP document in the browser opens the login dialog, r receives a third request, in this case a GET request 
for the path /redir with a parameter containing loginSessionToken. This is now used by r to look up the user’s session 
and redirect the user to the IdP (this redirection serves mainly to hide the referer string from the request to IdP). For this, 
r sends the script script_rp_redir and, in its initial script state, defines that the script should redirect the user to the URL 
of the login dialog (which is “https://” plus the domain of the user’s email address plus “/.well-known/spresso-login”). 

Finally, r receives a last request in the login flow. This POST request contains the encrypted IA and the 
loginSessionToken. . To conclude the login, r looks up the user’s login session, decrypts the IA, and checks that 
it is a signature over the tag, the user’s email address, and the FWD domain. If successful, r returns a new service token, 
which is also stored in the state of r. 

If r receives a corrupt message, it becomes corrupt and acts like the attacker from then on. 

We now provide the formal definition of r as an atomic DY process (I’,Z’,R r .sf). As mentioned, we define V = 
addr(r). Next, we define the set Z r of states of r and the initial state s q of r. 

Definition 45. A login session record is a term of the form (email, rpNonce.iaKey. tag) with email £ ID and rpNonce, 
iaKey, tag £ 

Definition 46. A state s £ Z r of an RP r is a term of the form (DNSAddress, FWDDomain, keyMapping, 
sslkeys, pendingDNS, pendingRequests, loginSessions, serviceTokens, wkCache, corrupt) where DNSAddress £ IPs, 
FWDDomain £ Doms, keyMapping £ [S x 9f], sslkeys = sslkeys r , pendingDNS £ x %\(]> pendingRequests £ 
\9f x T^y-], serviceTokens £ [9f x §], loginSessions £ x tZ^] is a dictionary of login session records, wkCache £ 
[S x , corrupt £ 

The initial state s' 0 of r is a state of r with s’ 0 . serviceTokens = Sq. loginSessions = Sq. wkCache = (), 
Sq. corrupt = L, and Sq. keyMapping is the same as the keymapping for browsers above. 

We now specify the relation R r . Just like in Appendix C, we describe this relation by a non-deterministic algorithm. 


Algorithm 8 Sending the response to a startLogin XMLHTTPRequest 

1: function SENDSTARTLOGINRESPONSEto, /, k, n, email, inDomain, s') 

2: let rpNonce := u\ 

3: let tagKey := uo 

4: let iaKey := ^3 

5: let loginSessionToken := ^4 

6 : let tag := enc s ({inDomain,rpNonce),tagKey) 

7: let s' .loginSess±ons[loginSessionToken] := (email, rpNonce, iaKey, tag) 

8 : let body := ((tagKey,tagAYy) (loginSessionToken, loginSessionToken), (FWDDomain,^.FWDDomain)) 

9: let m’ := enc s ((HTTPResp, 77 , 200 , (),body),k) 

10 : stop ((f,a,m')), s' 

11 : end function 


Algorithm 9 Relation of a Relying Party R r 


Input: (a,f,m),s 

1: if s'. corrupt f. L V m = CORRUPT then 
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2 : let /.corrupt := ({a, f,m),s'. corrupt) 

3: let m' 4—dy(s') 

4: let a' <— IPs 

5: stop ((a',a,m'}), s' 

6 : end if 

7: ii 3 (reference, request, key, f) G® s'.pendingRequests 

such that 7 Ti (dec s (m,fey)) = HTTPResp then > Encrypted HTTP response 

8 : let m! : = d ec s (m, key) 

9: if in 1 . nonce ^ request. nonce then 

10 : stop(),s 

11 : end if 

12: remove (reference, request,key, f) from s'.pendingRequests 

13: let a', f, k, n, email, inDomain such that (a!,f ,k,n, email, inDomain) = reference if possible; otherwise stop (), s 

14: let /.wkCache[regr<esr.host] := m'. body 

15: SENDSTARTLOGINRESPONSEfi/, f, k, n, email, inDomain, s') 

16: else if m £ DNSResponses then > Successful DNS response 

17: if m. nonce 0 s.pendingDNS V m. result ^ IPs Vm.domain ^ ^(s.pendingDNS).host then 

18: stop(),s 

19: end if 

20: let (reference,message) := s.pendingDNS[/n.nonce] 

21: let s'.pendingRequests := s'.pendingRequests 

<-4 +« (reference, message, v$, m. result) 

22: let message := enc a ((message, r's),/.keyMapping [message. host]) 

23: let s'.pendingDNS := s'.pendingDNS — m.nonce 

24: stop ((m. result, a,message)), s' 

25: else > Handle HTTP requests 

26: let 77Jdec> k, k!, inDomain such that 

e -> (m^ ec ,k) = dec a (m,£') A (inDomain,k!) £ s.sslkeys 
*-4 if possible; otherwise stop {), s 
27: let n, method, path, parameters, headers, body such that 

°4 (HTTPReq,n, method,inDomain,path,parameters,headers,body) = m ( j ec 
^4 if possible; otherwise stop {), s 

28: if path = / then > Serve index page. 

29: let m' := enc s ((HTTPResp,«,200, (), (script_rp, initState rp )),k) > Initial state defined for script_rp (below). 

30: stop ((f,a,m')), s' 

31: else if path = / startLogin A method = POST then > Serve start login request. 

32: if body qL ids then 

33: stop(),s 

34: end if 

35: let domain := body. domain 

36: if domain £ s.wkCache then 

37: SENDSTARTLOGINRESPONSE(a, f, k, n, body, inDomain, s') 

38: else 

39: let message : = (HTTPReq.t/g,GET, domain, /.well-known/spresso-inf o, (),(), ()) 

40: let s'.pendingDNS]^] := ((a, f,k,n,body,inDomain),message) 

41: stop ((s'.DNSaddress,a, (DNSResol we,domain,v^))), s' 

42: end if 

43: else if path = /redir l\method = GET then > Serve redirection script. 

44: let loginSession := s'.loginSessions[fe)iiy[loginSessionToken]] 

45: if loginSession = () then 

46: stop(),s 

47: end if 

48: let domain := loginSession. email.domain 

49: let params := ({email, loginSession. email), (tag, loginSession. tag), 

<-4 (iaKey,loginSession.iaKey), (FWDDomain,s'.FWDDomain)} 

50: let url := (URL, S, domain, / .well-known/spresso-login, params) 
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> Serve login request. 


51: let m! := enc s ((HTTPResp,n,200, (), (script_rp_redir, url)),k) 

52: stop (( f,a,m ')}, s' 

53: else if path = /login A method = POST then 

54: if /iearfen/Origin] ^ (inDomain, S) V t>ocfy[loginSessionToken] = () then 

55: stop(),s 

56: end if 

57: let loginSession := /.loginSessions^orfyfloginSessionToken]] 

58: if loginSession = (} then 

59: stop(),s 

60: end if 

61: let s'.loginSessions := s'.loginSessions — Zwcfy[loginSessionToken] 

62: let ia := dec s (body[eia],loginSession.iaKey) 

63: let e := {loginSession. tag, loginSession. email,sLFWDDomain} 

64: if checksig(c, w,.sFwkCache[/ogmSej\H07;.email.domain] [signkey]) = _L then 

65: stop(),s 

66 : end if 

67: let serviceTokenNonce := isj 

68 : let serviceToken := {serviceTokenNonce, loginSession. email) 

69: let s'.serviceTokens := s'.serviceTokens serviceToken 

70: let m! := enc s ((HTTPResp,n,200, (}, serviceToken),k) 

71: stop {{f,a,m')), s' 

72: end if 

73: end if 
74: stop (}, s 

D.13 Identity Providers 

An identity provider i £ IdPs is a web server modeled as an atomic process (I' ,Z' ,R' ,s' Q ) with the addresses /' := addr(t). 
Its initial state s' () contains a list of its domains and (private) SSL keys, a list of users and identites, and a private key 
for signing UCs. Besides this, the full state of i further contains a list of used nonces, and information about active 
sessions. 

IdPs react to three types of requests: 

First, they provide the “well-known document”, a machine-readable document which contains the IdP’s verification 
key. This document is served upon a GET request to the path /.well-known/spresso-inf o. 

Second, upon a request to the LD path (i.e., /.well-known/spresso-login), an IdP serves the login dialog script, 
i.e., script_idp. Into the initial state of this script, IdPs encode whether the browser is already logged in or not. 
Further, IdP issues an XSRF token to the browser (in the same way RPs do). 

The login dialog will eventually send an XMLHTTPRequest to the path loginxhr, where it retrieves the IA. This 
is also the last type of requests IdPs answer to. Before serving the response to this request, IdP checks whether the user 
is properly authenticated. It then creates the IA and sends it to the browser. 

Formal description. In the following, we will first define the (initial) state of i formally and afterwards present the 
definition of the relation R'. 

To define the initial state, we will need a term that represents the “user database” of the IdP i. We will call this term 
usersef. This database defines, which secret is valid for which identity. It is encoded as a mapping of identities to 
secrets. For example, if the secret secret\ is valid for the identites id | and the secret secret 2 is valid for the identity id 2 , 
the userset' looks as follows: 


usersef = [id \ '.secret \, idiy.secreta] 

We define usersef as userset 1 = ({(M,secretOflD(M)) u £ ID'}). 

Definition 47. A state s £ Z' of an IdP i is a term of the form {sslkeys, users, signkey, sessions, corrupt) where 
sslkeys = sslkeys 1 , users = usersef, signkey £ (the key used by the IdP i to sign UCs), sessions £ [A£x “T/yJ, 
corrupt £ (Z/y-. 
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An initial state s‘ () of i is a state of the form (sslkeys' ,usersef ,signkey(/), (),_L). 

The relation R' that defines the behavior of the IdP i is defined as follows: 

Algorithm 10 Relation of IdP R' 

Input: (a,f,m),s 
1: let s' := s 

2: if /.corrupt ^ ± V m = CORRUPT then 
3: let /.corrupt := ((a,f,m),s'. corrupt) 

4: let m! <— dy (s') 

5: let/ <— IPs 

6: stop ((a' ,a,m')), / 

7: end if 

8 : let m<iec> k, k', inDomain such that 

e -> (nidec i k) = dec a (m,/) A (inDomain,k!) 6 s. sslkeys 

e -4 if possible; otherwise stop (}, s 

9: let n, method, path, parameters, headers, body such that 

> (HTTPReq,?!, method,inDomain,path,parameters,headers,body) = mje c 

if possible; otherwise stop (}, s 

10: if path = /.well-known/spresso-inf o then > Serve support document. 

11: let wkDoc := ((signkey, pub(/.signkey)}} 

12: let m 1 := enc s ((HTTPResp,«,200, (),wkDoc) ,k) 

13: stop ((f,a,m')), s' 

14: else if path = /.well-known/spresso-login then > Serve login dialog. 

15: let sessionid := /:ea/er.s[Cookie] [sessionid] 

16: let email := s'.sess±ozts[sessionid] 

17: let m' := enc s ((HTTPResp,n,200, (}, (script_idp, (start, email, (}}}), k) > Initial scriptstate of script_idp (defined 

below). 

18: stop ((f,a,m')), s' 

19: else if path = / sign A method = POST then > Serve signing request. 

20: let sessionid := /tea/er/Cookie] [sessionid] 

21: let loggedlnAs := / ,sessions[sessionid\ 

22: if Zw/y[email] ^ loggedlnAs A to/y[password] ^ /.usersetffcocfyfemail]] then 

23: stop(),s 

24: end if 

25: let ia := sig((ftorfy[tag],Zwify[email],foMfy[FWDDomain]},/.signkey) 

26: let sessionid := v% 

21: let s' .sessions[sessionid\ : = (w/v[email[ 

28: let setCookie := (Set-Cookie, ((sessionid, sessionid, T,T, T}}) 

29: let m' := enc s ((HTTPResp,«,200, (setCookie),ia),k) 

30: stop ((f,a,m')), / 

31: end if 
32: stop (), s 

D.14 Forwarders 

We define FWDs formally as atomic DY processes fwd = ( f wd ,7f wd , R lwd , s^ d ). As already mentioned, we define 
pwd _ a ddr(/tvt/) with the set of states Zl wd being all terms of the form (sslkeys,corrupt) for sslkeys, corrupt £ % y-. 

The initial state J^ d of an FWD contains the private key of its domain and the corruption state: s^ d = (sslkeys/*" 1 ,!-). 
An FWD responds to any HTTPS request with script_fwd and its initial state, which is empty. 

We now specify the relation R lwd of FWDs. We describe this relation by a non-deterministic algorithm. 

Algorithm 11 Relation of an FWD R^ d _ 

Input: (a,f,m),s 

1 : if .s. corrupt CORRUPT then 

44 






2: let s'.corrupt := {(a, f,m),s. corrupt) 

3: let m' <— dy (s') 

4: let a' <— IPs 

5: stop ((a 1 ,a,m')), s' 

6 : end if 

7: let m ( ic C , k, k!, inDomain such that 

(m^ ec ,k) = dec a (?n,k') A (inDomain,k') G s 
if possible; otherwise stop (), i 
8 : let 77, method, path, parameters, headers, body such that 

(HTTPReq.n, method,inDomain,path,parameters,headers,body) = 777 (j ec 
^ if possible; otherwise stop (}, s 
9: let 777 ' := enc s ((HTTPResp,n,200, (), (script_fwd, ())),k) 

10 : stop ((/,0,777 '}),s 

D.15 DNS Servers 

As already outlined above, DNS servers are modeled as generic DNS servers presented in Appendix B.7. Their (static) 
state is set according to the allocation of domain names to IP addresses. DNS servers may not become corrupted. 

D.16 SPRESSO Scripts 

As already mentioned in Appendix D.l, the set S of the web system SWS = (W, S, script,/; 0 ) consists of the scripts R att , 
script_rp, script_idp, and script_fwd, with their string representations being att_script, script_rp, script_idp, 
and script_fwd (defined by script). 

In what follows, the scripts script_rp, script_idp, and script Jwd are defined formally. First, we introduce some 
notation and helper functions. 

Notations and Helper Functions. In the formal description of the scripts we use an abbreviation for URLs. We write 
URL p ath to describe the following URL term: (URL, S ,d,path, ()). 

In order to simplify the description of the scripts, several helper functions are used. 

CHOOSEINPUT. 

The state of a document contains a term scriptinputs which records the input this document has obtained so far 
(via XHRs and postMessages, append-only). If the script of the document is activated, it will typically need to pick 
one input message from the sequence scriptinputs and record which input it has already processed. For this purpose, 
the function CHOOSEINPUT (scriptinputs .pattern) is used. If called, it chooses the first message in scriptinputs that 
matches pattern and returns it. 


Algorithm 12 Choose an unhandled input message for a script 
1: function CHOOSEINPUT (script inputs, pattern) 

2: let 7 such that i = mi n { / : ttj (scriptinputs) ~ pattern} if possible; otherwise return _L 

3: return 7r {(scriptinputs) 

4: end function 

PARENTWINDOW. To determine the nonce referencing the active document in the parent window in the browser, 
the function PARENTWINDOW(tree, docnonce) is used. It takes the term tree, which is the (partly cleaned) tree of 
browser windows the script is able to see and the document nonce docnonce, which is the nonce referencing the current 
document the script is running in, as input. It outputs the nonce referencing the active document in the window which 
directly contains in its subwindows the window of the document referenced by docnonce. If there is no such window 
(which is the case if the script runs in a document of a top-level window) or no active document, PARENTWINDOW 
returns docnonce. 

SUBWINDOWS. This function takes a term tree and a document nonce docnonce as input just as the function above. 
If docnonce is not a reference to a document contained in tree, then SUBWINDOWSf tree,docnonce) returns (). 
Otherwise, let ( docnonce, origin, script, scriptstate, scriptinputs, subwindows, active) denote the subterm of tree 
corresponding to the document referred to by docnonce. Then, SU BWl N DOWS( tree. docnonce ) returns subwindows. 
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AUXWINDOW. This function takes a term tree and a document nonce docnonce as input as above. From all window 
terms in tree that have the window containing the document identified by docnonce as their opener, it selects one 
non-deterministically and returns its active document’s nonce. If there is no such window or no active document, it 
returns docnonce. 

OPENERWINDOW. This function takes a term tree and a document nonce docnonce as input as above. It returns the 
window nonce of the opener window of the window that contains the document identified by docnonce. Recall that the 
nonce identifying the opener of each window is stored inside the window term. If no document with nonce docnonce 
is found in the tree tree, 0 is returned. 

GETWINDOW. This function takes a term tree and a document nonce docnonce as input as above. It returns the nonce 
of the window containing docnonce. 

GETORIGIN. To extract the origin of a document, the function GETORIG I N (tree, docnonce) is used. This function 
searches for the document with the identifier docnonce in the (cleaned) tree tree of the browser’s windows and 
documents. It returns the origin o of the document. If no document with nonce docnonce is found in the tree tree, 0 is 
returned. 

GETPARAMETERS. Works exactly as GETORIGIN, but returns the document’s parameters instead. 

Relying Party Index Page (script_rp). As defined in Appendix A.3, a script is a relation that takes as input a term and 
outputs a new term. As specified in Appendix C (Triggering the Script of a Document (m = TRIGGER, action = 1)) and 
formally specified in Algorithm 5, the input term is provided by the browser. It contains the current internal state of the 
script (which we call scriptstate in what follows) and additional information containing all browser state information 
the script has access to, such as the input the script has obtained so far via XHRs and postMessages, information 
about windows, etc. The browser expects the output term to have a specific form, as also specified in Appendix C and 
Algorithm 5. The output term contains, among other information, the new internal scriptstate. 

We first describe the structure of the internal scriptstate of the script script_rp. 

Definition 48. A scriptstate s of script_rp is a term of the form ( q , loginSessionToken, refXUR, tagKey, FWDDomain) 
where q £ S, loginSessionToken, refX.HR, tagKey £ 7\£U {_!_}, FWDDomain £ 

The initial scriptstate initState rp of script_rp is (start, J_L,_L,_L). 

We now specify the relation scriptjrp formally. We describe this relation by a non-deterministic algorithm. 

Just like all scripts, as explained in Appendix C (see also Algorithm 5 for the formal specification), the input term 
this script obtains from the browser contains the cleaned tree of the browser’s windows and documents tree, the nonce 
of the current document docnonce, its own scriptstate scriptstate (as defined in Definition 48), a sequence of all inputs 
scriptinputs (also containing already handled inputs), a dictionary cookies of all accessible cookies of the document’s 
domain, the localStorage localStorage belonging to the document’s origin, the secrets secret of the document’s origin, 
and a set nonces of fresh nonces as input. The script returns a new scriptstate s', a new set of cookies cookies', a new 
localStorage localStorage' , and a term command denoting a command to the browser. 


Algorithm 13 Relation of script rp 

Input: (tree, docnonce, scriptstate, scriptinputs, cookies, localStorage, sessionStorage, 

'-»• ids, secret) 

1 : let s' : = scriptstate 
2 : let command := () 

3: let origin := GETORIGIN(tree, docnonce) 

4: switch s'.q do 
5: case start 

6 : let s'.email t— ids 

7: lets'.refXHR := A! 

8 : let command := (XMLHTTPREQUEST, POST,s'.email,s'.refXHR) 

9: let s'.q := expectStartLoginResponse 

10: case expectStartLoginResponse 

11: let pattern := (XMLHTTPREQUEST, *, s' .ref XHR) 
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12: let input := CHOOSEINPUT (scriptinputs,pattern) 

13: if input ^ _ then 

14: let s'.loginSessionToken := 7 r 2 (ni/»(?)[l°ginSessionToken] 

15: let s'.tagKey := it 2 {input)\ta.g¥,ey] 

16: let s'.FWDDomain := 7 T 2 (input) [FWDDomain] 

17: let command := 

(HREF, (URL, S, origin, domain, /redir, {{loginSessionToken,s'.loginSessionToken))),_BLANK, {}) 

18: let s'.q := expectFWDReady 

19: end if 

20: case expectFWDReady 

21: let fwdWindowNonce := SUBWINDOWSprce, AUXWINDOWRree, clocnonce)). l.nonce 

22: let pattern := {POSTVIESSAGE,fwdWindowNonce, {s'. FWDDomain, S), ready) 

23: let input := CHOOSEINPUT {scriptinputs,pattern) 

24: if input f _ then 

25: let command := {POSTMESSAGE, fwdWindowNonce, (tagKey ,tagKey), {s'.FWDDomain, S)) 

26: let s',q := expectEIA 

27: end if 

28: case expectEIA 

29: let fwdWindowNonce := SUBWINDOWSprce, AUXWINDOWRree, docnonce)). l.nonce 

30: let pattern := {POSTMESSAGE, fwdWindowNonce, {s'. FWDDomain, S), (eia, *}} 

31: let input := CHOOSE\NPUT(scriptinputs,pattern) 

32: if input ^ _L then 

33: let eia := ^{^(input)) 

34: lets'.refXHR := A[ 

35: let body := {{eia, eia), {loginSessionToken,s'.loginSessionToken)} 

36: let command := {XMLHTTPREQUEST, URL^"^ omaln ,P0ST,t)Ofi{y,/.refXHR) 

37: let s'.q := expectServiceToken 

38: end if 

39: stop {s', cookies, localStorage, sessionStorage , command) 

Relying Party Redirection Page (script_rp_redir). This simple script (which is loaded from RP in a regular run) is 
used to redirect the login dialog window to the actual login dialog (IdPdoc) loaded from IdP It expects the URL of the 
page to which the browser should be redirected in its initial (and only) state. 


Algorithm 14 Relation of script jrpjredir 

Input: {tree, docnonce, scriptstate, scriptinputs, cookies, localStorage, sessionStorage, 
ids, secret) 

1: let command := {HREF,scnpfsfafe,±,T} 

2: stop ( scriptstate, cookies, localStorage, sessionStorage, command) 

Login Dialog Script (script_idp). This script models the contents of the login dialog. 

Definition 49. A scriptstate s of script_idp is a term of the form (q, email) with q £ S, email € I D U {{)} £ T. We call 
the scriptstate s an initial scriptstate of script_idp iff s ~ {start, *). 

We now formally specify the relation script_idp of the LD’s scripting process. 


Algorithm 15 Relation of script_idp 

Input: {tree, docnonce, scriptstate, scriptinputs, cookies, localStorage, sessionStorage, 
e -» ids, secret) 

1 : let s' := scriptstate 
2 : let command := {) 

3: let origin := GETORIGIN {tree,docnonce) 

4: switch s '.q do 
5: case start 
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6 : let email := GETPARAMETERS(tree,i7ocnoncc)[email] 

7: let tag := GETPARAMETERS(frce,<toCT!07?ce)[tag] 

8 : let FWDDomain := GETPARAMETERS(free,<7ocnonce)[FWDDomain] 

9: let body := ({email, email), (password, secret), (tag, tag), (FWDDomain, FWDDomain)) 

10: let command := (XMLHTTPREQUEST, URL""^' domain .P0ST, body,!) 

11: let s'.q := expectIA 

12: case expectIA 

13: let pattern := (XMLHTTPREQUEST, *, *} 

14: let input := CHOOSEINPUT (scriptinputs,pattern) 

15: if input _L then 

16: let iaKey := GETPARAMETERS(tree,(foc7?o«ce)[iaKey] 

17: let FWDDomain := G ET PARAM ETE RS (free, docnonce) [FWDDomain] 

18: let tag := GETPARAMETERS(free,c(ocnonce)[tag] 

19: let eia : = enc s ( 772 (input),iaKey) 

20: let«r/: = (URL, S, FWDDomain,/, ((tag, tag), (eia, eia))) 

21: let command := (lFRAME,«r/,_SELF) 

22 : let s'.q := stop 

23: end if 

24: stop {s', cookies, localStorage, sessionStorage , command) 

Forwarder Script (script_fwd). 

Definition 50. A scriptstate ,v of script_fwd is a term of the form q with q € S. We call s the initial scriptstate of 
scriptffn’d iff s = start. 

We now formally specify the relation script_rp_index of the FWD’s scripting process. 


Algorithm 16 Relation of script_fwd 

Input: {tree, docnonce, scriptstate, scriptinputs, cookies, localStorage, sessionStorage, 

<-¥ ids, secret) 

1: let s 1 scriptstate 
2 : let command := (} 

3: let target := OPENERWINDOW(trcc,PARENTWINDOW(nre,rfocnonce)) 

4: switch s'. q do 
5: case start 

6 : let command := (POSTMESSAGE, target, ready, ±) 

7: let sGq := expectTagKey 

8 : case expectTagKey 

9: let pattern := {POSTMESSAGE, target, *, (tagKey,*)} 

10: let input := Ch\OOSE\NP\JT(scriptinputs,pattern) 

11: if input ^ _L then 

12: let tag Key := 777(774 (input)) 

13: let tag := GETPARAMETERS(free,doc?!once)[tag] 

14: let eia := GETPARAMETERS(tree,tfocno«ce)[eia] 

15: let rpOrigin := (dec s (tag,fagAey). 1, S) 

16: let command := {POSTMESSAGE, target, (eia, eia ), rpOrigin) 

17: let s'.q := stop 

18: end if 

19: stop {s', cookies, localStorage, sessionStorage, command) 

E Formal Security Properties Regarding Authentication 

To state the security properties for SPRESSO, we first define an SPRESSO web system for authentication analysis. This 
web system is based on the SPRESSO web system and only considers one network attacker (which subsumes all web 
attackers and further network attackers). 
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Definition 51. LetSWS‘" <,h = (TV, S, script, E°) an SPRESSO web system. We call SWS au,h an SPRESSO web system 
for authentication analysis iff TV contains only one network attacker process attacker and no other attacker processes 
(i.e., Net = {attacker}, Web = 0). Further, TV contains no DNS servers. DNS servers are assumed to be dishonest, 
and hence, are subsumed by attacker. In the initial state .Sg of each browser b in TV, the DNS address is addr(attacker). 
Also, in the initial state Sg of each relying party r, the DNS address is addr(attacker). 

The security properties for SPRESSO are formally defined as follows. First note that every RP service token (n,i) 
recorded in RP was created by RP as the result of an HTTPS POST request m. We refer to m as the request corresponding 
to ( n,i). 

Definition 52. Let Sl fS'"" 1 ' be an SPRESSO web system for authentication analysis. We say that SWS aul1 ' is secure if 
for every run p of SWS auth , every state (SfEfN^) in p, every r £ RP that is honest in with so(r).FWDDomain being 
a domain of an FWD that is honest in S J , every RP service token of the form ( n,i ) recorded in S J (r).serviceTokens, 
the following two conditions are satisfied: 

(A) If (n,i) is derivable from the attackers knowledge in S J (i.e., ( n,i ) £ d</)(S J (attacker))), then it follows that the 
browser b owning i is fully corrupted in S J (i.e., the value of isCorrupted is FULLCORRUPT) or governor(i) is not an 
honest IdP (in S J ). 

(B) If the request corresponding to ( n,i } was sent by some b £ B which is hottest in S J , then b owns i. 


F Proof of Theorem 2 

Before we prove Theorem 2, we show some general properties of the SWS auth ■ 

F.l Properties of SWS autb 

Let SdffS auth = (TP,5, script ,E°) be a web system. In the following, we write s x = (S X ,E X ,N X ) for the states of a web 
system. 

Definition 53. In what follows, given an atomic process p and a message m, we say that p emits m in a run p = 
(sO)Si, • • ■) if there is a processing step of the form 


for some u £ N, a set of events E and some addresses x, y with (. x,y,m ) £ E. 

Definition 54. We say that a term t is derivably contained in (a term) t' for (a set of DY processes) P (in a processing 
step Si —> Si + \ of a run p = (so,si ,■■■)) (A derivable from t' with the knowledge available to P, i.e., 

t£d»({t'}Vj{JS i+ \p)) 

peP 

Definition 55. We say that a set of processes P leaks a term t (in a processing step s, —> s,+i) to a set of processes 
P' if there exists a message m that is emitted (in si —> s,-+i) by some p £ P and t is derivably contained in m for P' in 
the processing step Sj -P .v,+ 1 . If we omit P', we define P' := < W\P. IfP is a set with a single element, we omit the set 
notation. 

Definition 56. We say that an DY process p created a message m (at some point) in a run if m is derivably contained 
in a message emitted by p in some processing step and if there is no earlier processing step where m is derivably 
contained in a message emitted by some DY process p'. 

Definition 57. We say that a browser b accepted a message (as a response to some request) if the browser decrypted 
the message (if it was an HTTPS message) and called the function PROCESSRESPONSE, passing the message and 
the request (see Algorithm 6). 
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Definition 58. In a similar fashion, we say that an RP r accepted a message (as a response to some request) if the RP 
decrypted the message (RPs can only accept HTTPS messages) and added the message’s body to the wkCache in its 
state (i.e.. Line 14 of Algorithm 9 was called). 

Definition 59. We say that an atomic DY process p knows a term t in some state s = (S. E ,N) of a run if it can derive 
the term from its knowledge, i.e., t £ d</)(S(p)). 

Definition 60. We say that a script initiated a request r if a browser triggered the script ( in Line 1 0 of Algorithm 5 ) and 
the first component of the command output of the script relation is either HREF, IFRAME, FORM, or XMLHTTPREQUEST 
such that the browser issues the request r in the same step as a result. 

For a run p = (so,si,...) of SWS auth , we state the following lemmas: 

Lemma 1. If in the processing step Si — ► .y ; + 1 of a run p of STfS‘"" h an honest relying party r (I) emits an HTTPS 
request of the form 


m = er\c a ((req,k),pub(k')) 

(where req is an HTTP request, k is a nonce (symmetric key), and k! is the private key of some other DY process u), 
and (II) in the initial state so the private key k’ is only known to u, and (III) u never leaks k!, then all of the following 
statements are true: 

1. There is no state of SkPS auth where any party except for u knows k’, thus no one except for u can decrypt req. 

2. If there is a processing step Sj —¥ Sj+ \ where the RP r leaks k to “W\ {u,r} there is a processing step Sh —> Sh +1 
with h < j where u leaks the symmetric key k to W\{u,r} or r is corrupted in sj. 

3. The value of the host header in req is the domain that is assigned the public key pub(^) in RP’s keymapping 
so-keyMapping (in its initial state). 

4. If r accepts a response (say, m’) to m in a processing step sj —> s /+ i and r is honest in Sj and u did not leak the 
symmetric key k to ‘W\ {u , r} prior to sj, then u created the HTTPS response m! to the HTTPS request m, i.e., the 
nonce of the HTTP request req is not known to any atomic process p, except for the atomic DY processes r and u. 

Proof. (1) follows immediately from the condition. If k! is initially only known to u and u never leaks k! , i.e., even with 
the knowledge of all nonces (except for those of u), k' can never be derived from any network output of u, k! cannot be 
known to any other party. Thus, nobody except for u can derive req from m. 

(2) We assume that r leaks k to ‘W \ { it. r} in the processing step sj —> sj + \ without u prior leaking the key k to 
anyone except for u and r and that the RP is not fully corrupted in Sj, and lead this to a contradiction. 

The RP is honest in s,. From the definition of the RP, we see that the key k is always a fresh nonce that is not used 
anywhere else. Further, the key is stored in pendingRequests. The information from pendingRequests is not extracted 
or used anywhere else, except when handling the received messages, where it is only checked against. Hence, r does 
not leak k to any other party in sj (except for u and r). This proves (2). 

(3) Per the definition of RPs (Algorithm 9), a host header is always contained in HTTP requests by RPs. From 
Line 22 of Algorithm 9 we can see that the encryption key for the request req was chosen using the host header of the 
message. It is chosen from the keyMapping in RP’s state, which is never changed during p. This proves (3). 

(4) An HTTPS response m! that is accepted by r as a response to m has to be encrypted with k. The nonce k is 

stored by the RP in the pendingRequests state information. The RP only stores freshly chosen nonces there (i.e., the 
nonces are not used twice, or for other purposes than sending one specific request). The information cannot be altered 
afterwards (only deleted) and cannot be read except when the browser checks incoming messages. The nonce k is only 
known to u (which did not leak it to any other party prior to sj) and r (which did not leak it either, as u did not leak 
it and r is honest, see (2)). The RP r cannot send responses that are encrypted by symmetric encryption keys used 
for outgoing HTTPS requests (all encryption keys used for encrypting responses are taken from the matching HTTPS 
requests and never from pendingRequests). This proves (4). □ 

Lemma 2. For every honest relying party r £ RP, every s £ p, every ( host,wkDoc ) £^ S(r ).wkCache it holds that 
wkDoc [signkey] = pub(signkey(dom _1 (host))) if dom -1 (host) is an honest IdP. 
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Proof. First, we can see that (in an honest RP) S(r) .wkCache can only be populated in Line 14 (of Algorithm 9). There, 
the body of a received message m! is written to S(r). wkCache. From Line 7 we can see that m' is the response to a 
HTTPS message that was sent by r. Only in Lines 39ff., r can assemble (and later sent) such requests. 

All such requests are sent to the path /.well-known/spresso-info. As the original request was stored in 
pendingRequests, in Line 14, we know that request. host is the domain the original request was encrypted for 
and finally sent to. 

With the condition of this lemma we see that dom -1 (request .host) is an honest IdP, say, p. Lemma 1 applies here 
and we can see that p created the HTTPS response, and it was not altered by any other party. In Algorithm 10 we can 
see that an honest IdP responds to requests to the path /.well-known/spresso-inf o in Line lOff. Here, p constructs 
a document wkDoc and sends this document in the body of the HTTPS response. This document is of the following 
form: ((signkey, pub^'.signkey))). The term s'.signkey is defined in Definition 47 to be signkey)/?) and is never 
changed in Algorithm 10. 

Therefore, a pairing of the form (request.host, x) with x [signkey] = pu b(sign key (dom~ 1 (request. host))) is stored 
in S(r). wkCache. As this applies to all pairings in S(r). wkCache, this proves the lemma. 

□ 


Definition 61. For every service token (n. i) we define a service token response for (n.i) to be an FITTPS response 
where the value n is contained in the body of the message. A service token request for (n.i) is an HTTPS request that 
triggered the sendee token response for ( n,i). 

Lemma 3. In a run p of SWS‘"' th , for every state Sj £ p, every RP r £ RP that is honest in Sj, every (n,i) £'- ) 
S J (r). serviceTokens, the following properties hold: 


1. There exists exactly one l' < j such that there exists a processing step in p of the form 


sr 


'■-►({a'./','"')) 


> S/'+l 


with d being some events, a’ and f being addresses and m' being a sendee token response for (n,i). 

2. There exists exactly one l < j such that there exists a processing step in p of the form 


si - --- > Si +1 


with e being some events, a and f being addresses and m being a service token request for (n, i). 

3. The processing steps from (1) and (2) are the same, i.e., I = l'. 

4. The sendee token request for (n, i), m in (2), is an HTTPS message of the following form: 


enc a (((HTTPReq, n req , POST, d r , /login, x,h, b),k ), pub(sslkey (d r ))) 
for d r £ dom(r), some terms x, h, n req , and a dictionary b such that 

i?[eia] = er\c s (s\g((tag f, S(r) .F]ilDDoma.in), k s i gn ), iaKey) 


with 

tag = enc s ((d r ,n rp ),tagKey), 

i = ^(rj.loginSessions^floginSessionToken]].email, 
tag = S / (r).loginSessions[h[loginSessionToken]].tag, 
iaKey = S , (r).loginSessions[/7[loginSessionToken]].iaKey 
for some nonces n rp , and k s i gn . 

5. If the governor of i is an honest IdP, we have that k s j gn = signkey(governor(i)). 
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Proof. (1). The service token nonce n of service tokens (n. i) (p .S -/ (V). serviceTokens can only be contained in a 
response that is assembled in Lines 53ff of Algorithm 9. The n is freshly chosen in Line 67, stored (along with the 
identity i) to S 7 /?-).serviceTokens (actually to S ? (r).serviceTokens for some q < j) in Line 69 and sent out in 
the service token response in Line 70f. The service tokens stored in A 7 /;-).serviceTokens are not used or altered 
anywhere else. Therefore, each service token nonce is sent in exactly one (service token) response. 

(2) . From Line 53 of Algorithm 9 it is easy to see that each service token response is triggered by exactly one request. 

(3) . Follows immediately from (2). 

(4) . The basic form of the encrypted HTTPS request, the host header, and the usage of the correct encryption key are 
enforced by Lines 26f. The path component is checked to be /login and the method component is checked to be POST 
in Line 53. The values of b[e ia], tag , and iaKey are checked in Lines 62ff. 

(5) . In Line 64, the term ia is checked to be signed with the signature key stored in S 9 (r).wkCache indexed under the 
domain of the email address i (for some q < j). With Lemma 2, we can see that for the domain of the email address i 
this signature key is sign key (doirL 1 ((.domain)). With doirL 1 (/.domain) = governor);) we can see that ia must have 
been signed with the signature key of the honest IdP that governs the email address i. Further, in the same line, the 
contents of the signature, including the tag, are checked. 

□ 


F.2 Property A 

As stated above, the Property A is defined as follows: 

Definition 62. Let SWS a " ,h be an SPRESSO web system for authentication analysis. We say that SfWS autl1 is secure 
(with respect to Property A) if for every run p of SW5 a " th , every state ( SfEfN 7 ) in p, every re RP that is honest in 
Si with A°(r).FWDDomain being a domain of an FWD that is honest in Sf every RP service token of the form (nf) 
recorded in S J (r). serviceTokens and derivable from the attackers knowledge in S J (i.e., ( n,i ) £ ^(^(attacker))), 
it follows that the browser b owning i is fully corrupted in S J (i.e., the value of isCorrupted is FULLCORRUPT) or 
governor);) is not an honest IdP (in A ■>). 

We want to show that every SPRESSO web system is secure with regard to Property A and therefore assume that 
there exists an SPRESSO web system that is not secure. We will lead this to a contradication and thereby show that all 
SPRESSO web systems are secure (with regard to Property A). 

In detail, we assume: There exists an SPRESSO web system SWS aMh , a run p of SWS autb , a state Sj = (SfEfN ; ) 
in p, a RP r £ RP that is honest in S 7 with S°(r).FWDDomain being a domain of an FWD that is honest in Sf an RP 
service token of the form (nf) recorded in S ] (r). serviceTokens and derivable from the attackers knowledge in S J 
(i.e., (nf) £ r/ 0 (S ; (attacker))j, and the browser b owning i is not fully corrupted and governor);) is an honest IdP (in 
Si). 

We now proceed to to proof that this is a contradiction. First, we can see that for (nf) and sj, the conditions in 
Lemma 3 are fulfilled, i.e., a service token request m and a service token response in' to/from r exist, and m! is of form 
shown in Lemma 3 (4). Let I := governor);). We know that I is an honest IdP. As such, it never leaks its signing key 
(see Algorithm 10). Therefore, the signed subterm ia := sig((tag,;,5(r).FWDDomain),signkey(/)) had to be created by 
the IdP I. An (honest) IdP creates signatures only in Line 25 of Algorithm 10. 

Lemma 4. Under the assumption above, only the browser b can issue a request (say, m cert ) that triggers the IdP I to 
create the signed term ia. The request m cert was sent by b over HTTPS using I’s public HTTPS key. 

Proof. We have to consider two cases for the request m cen : 

(A). First, if the user is not logged in with the identity i at I (i.e., the browser b has no session cookie that carries a 
nonce which is a session id at I for which the identitiy ; is marked as being logged in, compare Line 22 of Algorithm 10), 
then the request has to carry (in the request body) the password matching the identity i (secretOfID);)). This secret is 
only known to b initially. Depending on the corruption status of b, we can now have two cases: 

a) If b is honest in Sj , it has not sent the secret to any party except over HTTPS to I (as defined in the definition of 
browsers). 
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b) If b is close-corrupted, it has not sent it to any other party while it was honest (case a). When becoming close- 
corrupted, it discarded the secret. 

I.e., the secret has been sent only to I over HTTPS or to nobody at all. The IdP I cannot send it to any other party. 
Therefore we know that only the browser b can send the request m cer t in this case. 

(B). Second, if the user is logged in for the identity i at 7, the browser provides a session id to I that refers to a logged 
in session at I. This session id can only be retrieved from I by logging in, i.e., case (A) applies, in particular, b has to 
provide the proper secret, which only itself and I know (see above). The session id is sent to b in the form of a cookie, 
which is set to secure (i.e., it is only sent back to I over HTTPS, and therefore not derivable by the attacker, see prior 
work ) and httpOnly (i.e., it is not accessible by any scripts). The browser b sends the cookie only to I. The IdP I never 
sends the session id to any other party than b. The session id therefore only leaks to b and 7, and never to the attacker. 
Hence, the browser b is the only atomic DY process which can send the request m cer t in this case. 

We can see that in both cases, the request was sent by b using HTTPS and /’s public key: If the browser would intend 
to sent the request without encryption, the request would not contain the password in case (A) or the cookie in case (B). 
The browser always uses the “correct” encryption key for any domain (as defined in SWS a “ ')■ □ 

As the request m ctn is sent over HTTPS, it cannot be altered or read by any other party. In particular, it is easy to see 
that at the point in the run where m cert was sent, b was honest (otherwise, it would have had no knowledge of the secret 
anymore). 

Lemma 5. In the browser b, the request m cert was triggered by script_idp loaded from the origin (d,S) for some 
d £ dom(7). 

Proof. First, (d, S) for some d £ dom(7) is the only origin that has access to the secret secretOflD(;) for the identity i 
(as defined in Appendix D. 1 1). 

With the general properties defined in [11] and the definition of Identity Providers in Appendix D. 13, in particular 
their property that they only send out one script, script_idp, we can see that this is the only script that can trigger a 
request containing the secret. □ 

Lemma 6. In the browser b, the script script_idp receives the response to the request m cert (and no other script), and 
at this point, the browser is still honest. 

Proof. From the definition of browser corruption, we can see that the browser b discards any information about 
pending requests in its state when it becomes close-corrupted, in particular any SSL keys. It can therefore not decrypt 
the response if it becomes close-corrupted before receiving the response. 

The rest follows from the general properties defined in [11], □ 

We now know that only the script script_idp received the response containing the IA. For the following lemmas, 
we will assume that the browser b is honest. In the other case (the browser is close-corrupted), the IA ia and any 
information about pending HTTPS requests (in particular, any decryption keys) would be discarded from the browser’s 
state (as seen in the proof for Lemma 6 ). This would be a contradiction to the assumption (which requires that the IA 
arrived at the RP). 

Lemma 7. After receiving ia, script_idp forwards the ia only to an FWD that is honest (in sj, and therefore, also at 
any earlier point in the run) and a document script_fwd that was loaded from this FWD over HTTPS. 

Proof. We know that the browser b is either close-corrupted (in which case the ia would be discarded as it is only 
stored in the window structure, or, more precisely, the script states inside the window structure of the browser, which 
are removed when the browser becomes close-corrupted) or it is honest. In the latter case, script_idp (defined in 
Algorithm 15) opens an iframe from the FWDDomain that was given to it by RP. It always uses HTTPS for this request. 

We can see that script_idp forwards the ia to the domain stored in the variable FWDDomain (Line 20 of Algo¬ 
rithm 15). This variable is set five lines earlier with the value taken from the parameters of the current document. While 
we cannot know the actual value of the parameter FWDDomain yet, we know that this parameter does not change (in 
the browser definition, it is only set once, when the document is loaded). We can also see that the very same parameter 
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was sent to I in Line 10 as the value for the FWD domain that was then signed by I in the ia. As we know the value of 
the FWD origin in the ia (it is S(r).FWDDomain), we know that the domain to which the ia is forwarded is the same. 

From our assumption, we know that .S’(V).FWDDomain is the origin of an honest FWD in sj. It is contacted over 
HTTPS, so the general properties defined in [11] apply. According to the definition of forwarders (Algorithm 1 1), they 
only respond with script Jwd. The ia is therefore only forwarded to the FWD and its script scriptJwd. □ 

Lemma 8. The script script Jwd forwards the ia only to the script script_rp loaded from the origin ( d r , S). 

Proof. The script script_idp that runs in the honest browser b forwards the (then encrypted) IA along with the tag to 
script Jwd. From the definition of the IdP script (Algorithm 15) it is clear that the tag that is forwarded along with the 
encrypted IA is the same that was signed by the IdP. 

This script (Algorithm 11) tries to decrypt the tag (once it receives a matching key) and sends a postMessage 
containing the encrypted IA to the domain contained in the tag, which is d r . 

The protocol part of the origin is HTTPS. The only document that r delivers and which receives postMessages is 
script_rp, and this therefore is the only script that can receive this postMessage. □ 

Lemma 9. From the RP document, the EIA is only sent to the RP r and over HTTPS. 

Proof. This follows immediately from the definition of script_rp (see Algorithm 13, in particular Line 36 in conjunction 
with Line 3) and the fact that the RP document must have been loaded from the origin (d r , S) (as shown above). 

With Lemmas 6-9 we see that the ia, once it was signed by /, was transferred only to r, the browser b, and to an 
honest forwarder. It cannot be known to the attacker or any corrupted party, as none of the listed parties leak it to any 
corrupted party or the attacker. 

Now, for (n, i) to be created and recorded in Sjr ), a message m as shown above has to be created and sent. This can 
only be done with knowledge of eia. From their definitions, we can see that neither I, r nor any forwarder create such a 
message, with the only option left being b. If b sends such a request, it is the only party able to read the response (see 
general security properties in [11]) and it will not do anything with the contents of the response (see Algorithm 13), in 
particular not leak it to the attacker or any corrupted party. 

This is a contradication to the assumption, where we assumed that (n,i) £ d$(S-i( attacker)). This shows every 
SWS a " ,h is secure in the sense of Property A. 


F.3 Property B 

As stated above. Property B is defined as follows: 

Definition 63. Let SUlS'"" 1 ' be an SPRESSO web system. We say that SPtfS" 1 " 1 ' is secure (with respect to Property B) if 
for every run p ofSWS auth , every state (SfEfN j in p, every r £ RP that is honest in S' with 5°(r).FWDDomain being 
a domain of an FWD that is honest in S J , every RP sendee token of the form ( n,i } recorded in S J (r). serviceTokens, 
with the request corresponding to ( n,i ) sent by some b £ B which is honest in S J , b owns i. 

Applying Lemma 3 (1—4), we call the request corresponding to (n.i) (or service token request) m and its response 
in', and (as in Lemma 3 (2)) we refer to the state of SWS auth in the run p where r processes m by s /. 

Lemma 10. The request m was sent by script _rp loaded from the origin (d r , S) where d r is some domain of r. 

Proof. The request m is XSRF protected. In Algorithm 9, Line 54, RP checks the presence of the Origin header and 
its value. If the request m was initiated by a document from a different origin than (d, , S), the (honest!) browser b 
would have added an Origin header that would not pass this test (or no Origin header at all), according to the browser 
definition. The script script_rp is the only script that the honest party r sends as a response and that sends a request to 
r. □ 
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Lemma 11. The request m contains a nonce loginSessionToken such that 

S 1 (r) ,loginSessions[loginSessionToken]. email = i 
and b owns i!, i.e., ownerOflD(i / ) = b. 

Proof. With Lemma 10 we know that the request was sent by script_rp. In Algorithm 13 defining script_rp, in Line 35, 
the body of the request m is assembled (and this is the only line where this script sends a request that contains the 
same path as m). The login session token is taken from the script’s state ( loginSessionToken ). This part of the state is 
initially set to _L and is only changed in Line 14. There, it is taken from the response to the start login XHR issued in 
Line 8 (the request and response are coupled using rejXHR which is tracked in the script’s state). In Line 6, the script 
selects one of the browser’s identities (which are the identities that the browser owns, by the definition of browsers in 
Appendix D.l 1). This identity is then used in the start login XHR. 

When receiving this request (which is an HTTPS message, and therefore, cannot be altered nor read by the attacker), 
ultimatively, the function SENDSTARTLOGINRESPONSE (Algorithm 8) is called. There are two cases how this 
function can be called (see Line 36 of Algorithm 9): 

• If the well-know cache of r already contains an entry for the host contained in the email address, 
SENDSTARTLOGINRESPONSE is called immediately with the email address contained in the request’s body. 

• Else, the email address in the request’s body is stored, together with the request’s HTTP nonce, the HTTPS encryp¬ 
tion key and other data, in the subterm pendingDNS of r’s state. From there, it is later moved to pendingRequests 
(Line 21). Finally, in Line 15, SENDSTARTLOGINRESPONSE is called. 

We will come back to these two cases further down. 

After SENDSTARTLOGINRESPONSE is called, a new loginSessionToken is chosen and in the dictionary 
S x (r).loginSessions[loginSessionToken] the email address (along with other data) is stored (for some x). 

The loginSessionToken is then sent as a response to m, in particular, it is encrypted with the symmetric key k 
contained in the request. In the first case listed above, the k is immediately retrieved from the request. Otherwise, the 
relationship between k and the email address is preserved in any case: If the receiver can decrypt the response to m, it 
sent the email address i' in the request. 

As explained above, script_rp takes the loginSessionToken from the response body and stores it in its state to later 
use it in the request m. Therefore the start login XHR described above must have taken place before m, i.e., x < l. 

The entries in the dictionary loginSessions can not be altered and only be removed when a service token request 
with the corresponding value of loginSessionToken is processed. As each loginSessionToken is not leaked to any other 
party except r, we know that S , (r).loginSessions[/o,gbiSe.s.s/o«7bA:eH].email = i'. As shown above, due to the way 
i' is selected by the script, b owns i!. □ 

With Lemma 11 , we can now show that i = i': In Line 68 of Algorithm 9, the service token is assembled. In particular, 
i is chosen to be S l (r). loginSessions [loginSessionToken]. email, and therefore i = i! and b owns i. 


G Indistinguishability of Web Systems 

Definition 64 (Web System Command and Schedule). We call a term ( a web system command (or simply, com¬ 
mand) if C, is of the form 

{f ji 'TprocessWttldswitch iCmd w i nc i ow , T scr ipt , Urlj 

The components are defined as follows: 

• i e N, 

• 7'eN, 

• cmdswitch kz { 1 , 2 , 3 }, 

• Cmd w indow £ ^ > 
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• T scr i pt £ ^(V script U {x}) with x being a variable and V scr ip t the set of placeholders for scripting processess (see 
Definition 18). 

• 'fprocess € fibiyprocess U {x}) with x being a variable and V pr0 cess the set of placeholders (see Definition 4). 

• url £ URLs with URLs being the set of all valid URLs (see Definition 25). 

We call a (finite) sequence <r = ({ i,..., {„), with ,..., being web system commands, a web system schedule (or 
simply, schedule). 

Definition 65 (Induced Processing Step). Let TVS' = (TV, 5,script. L°) be a web system and 

{S , E ,N)^L!^iy { s',E',N') 

p—*E out 

be a processing step of TV (as in Definition 13) with E = (e\,e 2 , ■ ■ ■) and 

C = ( 1 h j ? 7 process 5 cmdswitch , cmd window,'tscript 1 url) 
a web system command. We say that this processing step is induced by { iff 

1. ei = (a,f,m). 

2. Under a lexicographic ordering of TV, p is the j-th process in TV with a £ I p . 

3. E = E ou t • (fq,..., ei— \, ,...). 

4. If p is a (web) attacker process or p is a corrupted browser (i.e., £(/?).isCorrupted ^ _L), then E out = (e ou t) with 

{S (P), eout) = t~process\{ei,s)jx]f. 

5. If p is an honest browser (i.e., S(p).isCorrupted = _L) and m = TRIGGER, the browser relation behaves as 
follows and E out and S' (p) are obtained accordingly: 

(a) If cmd switch = L the browser relation chooses switch = 1 in Line 9 of Algorithm 7 and w in Line 11 of 
Algorithm 7 such thatw is the cmd W i nc i ow -th window in the tree of browser’s state S(p). windows. If this script is 
not the attacker script, the browser (deterministically) executes the script in this window. Otherwise, in Line 10 
of Algorithm 5, the browser relation chooses the output of the script (of this window) as out A = T SC ript[in/x]f 
with the variable in (deterministically) chosen in Line 9 of Algorithm 5. 

(b) If cmd switch = 2, the browser relation chooses switch = 2 in Line 9 of Algorithm 7 and protocol, host, domain, 
path, parameters in Line 17ff. of Algorithm 7 such that url = (URL, protocol, host , path, parameters). 

(c) If cmd switch = 3, the browser relation chooses switch = 3 in Line 9 of Algorithm 7 and w in Line 24 of 
Algorithm 7 such thatw is the cmd W mdow-th window in the tree of browser’s state S(p). windows. (The browser 
then starts to reload the document in this window.) 

We write 

(S,E,N)^(S\E\N') . 

Corollary 1. In some cases a command o = {i,j, T proce ss : cmd sw it c h ? cm d w indow i Ucript ■ url) does not induce a processing 
step under the configuration ( S,E,N ) in a web system: Ifi > \E\, a processing step cannot be induced. The same applies 
if j does not refer to an existing process. Also, if the command schedules a TRIGGER message to be delivered to a 
browser p, cmd sw i tc h € {1,3}, and cmd W j n d ow > |Subwindows(S(/?))| (i.e., the command chooses a window of the 
browser p, which does not exist), then no processing step can be induced. 

Definition 66 (Induced Run). Let “WS = (Tl' 1 .5,script./-’ 0 ) be a web system, a = (fi,...,(„) be a finite web 
system schedule, and N° be an infinite sequence of pairwise disjoint nonces. We say that a finite run p = 
((S 0 ,E°,N°),...,(S n 1 E n ,N n )) of the system TV is induced by a under nonces N° iff for all 1 < i < n, Q induces 
the processing step 

(S’~ l ,E'~ l (SfEfN 1 ) . 

We denote the set of runs induced by a under all infinite sequences of pairwise disjoint nonces N° by a(‘WS). 

To define the notion of indistinguishability for web systems, we need to define the notion of static equivalence of 
terms in our model. This definition follows the notion of static equivalence by Abadi and Fournet [1], 
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Definition 67 (Static Equivalence). Lei t\, t 2 G ‘Py (V) be two terms with V a set of variables. We say that t\ and t 2 
are statically equivalent, written t\ « t 2 , iff for all terms M, N G ^({.t}) with x a variable and x ^ V, it holds true that 

M[ti/x]=N[ti/x] <G> M[t 2 /x\=N[t 2 /x\. 

Definition 68 (Web System with Distinguished Attacker). Let ‘WS = (Tf 2 .5, script, iff ) be a web system with ‘W 
partitioned into Hon, Web, and Net (as in Definition 21). Let attacker G W be an attacker process (out o/WebU Net). 
We call IfiS = ('If,S, script, E°, attacker) a web system with the distinguished attacker attacker. 


Definition 69 (Indistinguishability). Let WSo = ( 1 tt ; o,5o,script 0 ,£ , Q,po). IfSi = ('W ; i,J>i,script 1 ,£ , [ , ,/?i) be web 
systems with a distinguished attacker. We call WS o and WS \ indistinguishable under the schedule a iff for every 
schedule a and every i G {0,1}, we have that for every run p G a(WSi) there exists a run p' G a(‘WS\-i) such that 
P(Pi) ~ P'(PH)' 

We call “WS o and WSi indistinguishable iff they are indististinguishable under all schedules a. 


H Formal Proof of Privacy 

We will here first describe the precise model that we use for privacy. After that, we define an equivalence relation 
between configurations, which we will then use in the proof of privacy. 

H.l Formal Model of SPRESSO for Privacy Analysis 

Definition 70 (Challenge Browser). Let dr some domain and b(dr) a DYprocess. We call b(dr) a challenge browser 
iff b is defined exactly the same as a browser (as described in Appendix C) with two exceptions: (1) the state con¬ 
tains one more property , namely challenge, which initially contains the term T. (2) Algorithm 4 is extended by the 
following at its very beginning: It is checked if a message m is addressed to the domain CHALLENGE (which we call the 
challenger domain). If m is addressed to this domain and no other message m' was addressed to this domain before 
(i.e., challenge ^ _L), then m is changed to be addressed to the domain dr and challenge is set to _L to recorded that a 
message was addressed to CHALLENGE. 

Definition 71 (Deterministic DY Process). We call a DY process p = (I p ,Z P ,R P ,Sq) deterministic iff the relation R p 
is a (partial) function. 

We call a script R scr i pt deterministic iff the relation R scr ipt is a (partial) function. 

Definition 72 (SPRESSO Web System for Privacy Analysis). Let SIP'S = (‘If .S.script.E°) be an SPRESSO 
web system with W = Hon U Web U Net, Hon = B U RP U IDP U FWD U DNS (as described in Appendix D.l), 
RP = {n,r2}, FWD = {fwd}, DNS = {dns}, r\ and r 2 two (honest) relying parties, fwd an honest forwarder, 
dns an honest DNS server. Let attacker G Web be some web attacker. Let dr be a domain of r\ or r? and b(dr) 
a challenge browser. Let Hon 7 := {b(dr)} U RP U FWD U DNS, Web 7 := Web, and Net 7 := 0 (i.e., there is no net¬ 
work attacker). Let W := Hon 7 U Web 7 U Net'. Let S' '■= S\ {script_idp} and script 7 be accordingly. We call 
SfWS p " v (dr) = (W,S', script 7 , E°, attacker) an SPRESSO web system for privacy analysis iff the domain fwddomain 
is the only domain assigned to fwd, the domain dr\ the only domain assigned to r\, and t/ri the only domain assigned 
to r 2 - Both, r\ and r 2 are configured to use the fomarder fwd, i.e., in their state FWDdomain is set to fwddomain. The 
browser b(dr ) owns exactly one email address and this email address is governed by some attacker. All honest parties 
(in Hon) are not corruptible, i.e., they ignore any CORRUPT message. Identity providers are assumed to be dishonest, 
and hence, are subsumed by the web attackers (which govern all identities). In the initial state Sq of the (only) browser 
in W and in the initial states Sq , s (f of both relying parties, the DNS address is addr(dns). Further, wkCache in the 
initial states s'f, Sq 2 is equal and contains a public key for each domain registered in the DNS server (i.e., the relying 
parties already know some public key to verify SPRESSO identity assertions from all domains known in the system and 
they do not have to fetch them from IdP). 
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As all parties in an SPRESSO web system for privacy analysis are either web attackers, browsers, or deterministic 
processes and all scripting processes are either the attacker script or deterministic, it is easy to see that in SPRESSO 
web systems for privacy analysis with configuration (S,E,N) a command ( induces at most one processing step. 
We further note that, under a given infinite sequence of nonces N°, all schedules a induce at most one run p = 
((S°,E°,N °),..., (S l ,E l ,N l ),..., (Sl CT l ,Al <7 l)) as all of its commands induce at most one processing step for the 
j'-th configuration. 

We will now define our privacy property for SPRESSO: 

Definition 73 (IdP-Privacy). Let 

SWS 1 ” 1 ' := SWS P "' (dr\) = (Wi,S, script,£°, attacker;) and 
SWS 2 m := SWS P "'(dr 2 ) = {LV 2 ,S, script,£°, attacker) 

be SPRESSO web systems for privacy analysis. Further, we require attackeri = attacker 2 =: attacker and for b\ := 
b(dr i), b 2 •— b{drf) we require S(b\) = £(£> 2 ) and C W\ \ {f>i} = TP 2 \ {b 2 } (i-C., the web systems are the same up to the 
parameter of the challenge browsers). We say that SWS P "' is IdP-private iff SWS P "' and SLfS 2 "' are indistinguishable. 

H.2 Definition of Equivalent Configurations 

Let = (‘f1 / i,5,script, E°, attacker) and SWS , 2 ' V = ( e Mb,S, script, E°, attacker) be SPRESSO web systems for 

privacy analysis. Let (S\,E\,N\) be a configuration of SkfiS 1 ”" and (S 2 ,E 2 ,N 2 ) be a configuration of STffS p "'. 

Definition 74 (Proto-Tags). We call a term of the form enc s ((y, n ), k) with the variable y as a placeholder for a domain, 
and n and k some nonces a proto-tag. 

Definition 75 (Term Equivalence up to Proto-Tags). Let 9 = {a\,... ,a/} be a finite set of proto-tags. Let t and t' be 
terms. We call t\ and t 2 term-equivalent under a set of proto-tags 9 iff there exists a term t € ({x 1 ,... ,x;}) such that 

t\ = {T[ai/x\,... 1 ai/xi])[dri/y\ and t 2 = (r[ai /xu... ,a, /xi])[dr 2 /y\. We write t\ t 2 . 

We say that two finite sets of terms D and D' are term-equivalent under a set of proto-tags 9 iff\D\ = \D'\ and, given 
a lexicographic ordering of the elements in D of the form (d\,... ,d i d i) and the elements in D' of the form (d[,... ,di D ii), 
we have that for all i € { 1,..., |Dj}; c/,- d\. We then write D ^±g D'. 

Definition 76 (Equivalence of HTTP Requests). Let ni\ and m 2 be (potentially encrypted) HTTP requests and 
9 = {fli,...,«/} be a finite set of proto-tags. We call m\ and m 2 ^-equivalent under a set of proto-tags 9 iff m\ ^g m 2 
or all subterms are equal with the following exceptions: 

1. the Host value and the Origin/Referer headers in both requests are the same except that the domain dr\ in m\ can 
be replaced by dr 2 in m 2 , 

2. the HTTP body gi of m\ and the HTTP body g 2 of m 2 are (I) term-equivalent under 9, (II) for j € {1,2} if 
gj[eia] ~ enc s (sig((en c s ((drj, *),*), *,fwddomain), *), *) and the origin (HTTP header) of HTTP message in nij 
is (drj, S) then the receiver of this message is rj, and (III) if g\ contains a dictionary key loginSessionToken 
then there exists an l' £ L such that g\ [loginSessionToken] = l’, and 

3. if mi is an encrypted HTTP request then and only then m 2 is an encrypted HTTP request and the keys used to 
encrypt the requests have to be the correct keys for dr\ and dr 2 respectively. 

We write m\ —g m 2 . 


Definition 77 (Extracting Entries from Login Sessions). Let t\, t 2 be dictionaries over 9f and ‘T^f , 9 be a finite set 
of proto-tags, and d a domain. We call t\ and t 2 ^-equivalent iff t 2 can be constructed from t\ as follows: For every 
proto-tag a £ 9, we remove the entry identified by the dictionary key ifor which it holds that -K<i(t\ [/]) = a[d /y\, if any. 
We denote the set of removed entries by D. We write t\ \> e d ( t 2 ,D ). 
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Definition 78. Let a be a proto-tag, Si and S 2 be states of SPRESSO web systems for privacy analysis, and l a nonce. 
We call l a login session token for the proto-tag a, written l £ loginSessionTokens(a,Si ,Sf) iff for any i £ {1,2} and 
any j £ {1,2} we have that 7 T 4 (S ( (r^).loginSessions[Z]) = a[drj/y\. 

Definition 79 (Equivalence of States). Let 9 be a set of proto-tags and H be a set of nonces. Let K := {k \ 3n : 
en c s ((y,n) ,k) £ 6 }. We call Si and Si 7 -equivalent under ( 9,H ) iff the following conditions are met: 

1 . Si (fwd) = S 2 (fwd), and 

2. Si(dns) = Si(dns), and 

3. Si (ri) equals S 2 (ri) except for the subterms pendingDNS, loginSessions and serviceTokens, and 

4. Si ( 72 ) equals S 2 (r 2 ) except for the subterms pendingDNS, loginSessions and serviceTokens, and 

5. for two sets of terms D and D': Si(ri).loginSessions (S 2 (ci).loginSessions, D), 

S 2 (r 2 ).loginSessions >^ r2 (Si (r 2 ).loginSessions, D'), and D D', and 

6 . for all entries x in the subterms pendingDNS of Si (ri). Si (ri). Si (ri), and Si (ri) it holds true that 7 T 2 V.host is not 
a domain name known to the DNS seri’er, and 

7. the subterms pendingRequest o/Si(ri), Si(r 2 ), S 2 (ri), and S 2 (r 2 ) are (), and 

8 . the subterm wkCache o/Si(ri), Si(r 2 ), S 2 (ri), and S 2 (r 2 ) are equal and contain a public key for each domain 
registered in the DNS server, and 

9. \/k € K. k ^ r/ 0 (Ui'e{l, 2 }, AeWebUNetU{dns,fwd} Si(A)) 

10. for each attacker A: Si (A) g 82 (A), and 

11. for all a £ 9 and all attackers A we have that $ l £ loginSessionTokens(a,Si,S 2 ) such that l is a subterm of Si (A) 
orS 2 (A). 

12. Si(bi) equals S 2 (b 2 ) except for for the subterms challenge, pendingDNS, pendingRequests, windows and we 
have that 

(a) Si (b \).challenge = dri AS 2 (^ 2 ).challenge = dr 2 or Si (bf ).challenge = S 2 (b 2 ).challenge = _L, and 

(b) |Si(Z?i).pendingDNS| = |S 2 (Z? 2 )-P ell dingDNS| =: j, for all i £ {1,...,}}, qi := 7T ( (Si(Z?i).pendingDNS), 
92 '■= 7T/'(S2(^2)-pendingDNS) we have that tt\(qi) = 717 (< 72 ) €E Uf and for Vi := tt 2 (q\) and 17 := ^ 2 (^ 2 )-' 

i. 7r 1 (v 1 ) = 7r 1 ( 17 ), and 

ii. 7 r 3 (v 1 ) = 7 T 3 (V 2 ), and 

Hi. 7T 1 (vi) is either a nonce (£ Uf) or a term of the form (x,y) with x £ Ufa nonce and y £ UfU { _L} a nonce 
or _L, and 

iv. if 7T2 (vi ).host = dri A7T2(v2).host = dr 2 , 
then 7 T 2 (vi) — g ^ 2 ( 37 ) A 7r2(vi).nonce £ H, 

else 7T2(vi) ^ 2 (^ 2 ) A 7T2(vi). nonce ^ H A$l £ L such that l is a subterm 0 / 772 ( 37 ), 

and 

(c) |Si(Z?i).pendingRequests| = |S 2 (Z? 2 )-pendingRequests| =: j, for all i £ {1,...,}}, vi := 
7 r,(Si(/7i).pendingRequests), V 2 := 7r,(S2(Z?2)-pendingRequests) we have that 

i. 7Ti(vi) = 7Ti(v2), and 

ii. 7T3 (vi) = ttffvf), and 

iii. 7T 1 (vi) is either a nonce (£ Uf) or a term of the form (x,y) with x £ Ufa nonce and y £ Ufl\ { _L} a nonce 
or _L, and 

iv. if 7T2(vi).host = dri A7T2(v2).host = dr 2 , 

then 7T2(vi) — 0 7T2(v2) A 7t2(vi).nonce £ H A ttffvi) £ addr(n) A 774 ( 17 ) € addr/ 2 ), 

else 7T2(vi) 7r2(v2) A 7T2(vi).nonce ^ H A 7T4(vi) = 7r 4 ( 37 ) A $1 £L such that l is a subterm oftt 2 (vi), 

and 

(d) there is no k £ K such that 

k £ ({Si (bi ).pendingRequests,S2(i>2) .pendingRequests, 

Si (Z?i (.pendingDNS,S 2 (^ 2 )-P ell dingDNS}) 

(i.e., k cannot be derived from these terms by any party unless it knows k), and 
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(e) Si (b\). windows equals S 2 (b 2 ) .windows with the exception of the subtenns location, referrer, 
scriptstate, and scriptinputs of some document terms pointed to by Docs + (Si(£>i)) = 
Docs + (S 2 {b 2 )) ='■ J- For all j £ J we have that: 

i. there is no k £ K such that 

k £ d^{ k }({Si (b\).j .location, S 2 (b 2 ).j .location, 

Si (b\).j.ref errer ,S 2 (b 2 ).j .ref errer}) 

ii. if Si (bi).j. origin £ {(dr 1 , S), (dr 2 , S)} then Si (bi).j. script £ {script_rp, script_rp_redir}, and 
Hi. if Si (bfj.j. origin = (fwddomain,S) then Si(b\).j. script = script_fwd, and 

iv. if Si (bi).j. origin £ {(dr 1 , S), (dr 2 , S)} and Si (bi ).j. script = script_rp then 

A. Si(bi).j. location and S 2 (b 2 ) - j-location are term-equivalent under 9 except for the host part, 
which is either equal or dr 1 in bi and dr 2 in b 2 , and 

B. Si(bi).j. referrer and S 2 (b 2 )-j-xef errer are term-equivalent under 9 except for the host part, 
which is either equal or dr 1 in b 1 and dr 2 in b 2 , and 

C. Si (bi).j. scriptstate ^g S 2 (b 2 ).j .scriptstate and if 31 £ L such that l is a subterm of 
Si(bi).j. scriptstate, then Si (bi).j. location.host = dr 1 and S 2 {b 2 ) -j .iocation.host = dr 2 , 
and 

D. for p£{ 

(XMLHTTPREQUEST,*, *), 

(POSTMESSAGE, *, (fwddomain.S), ready), 

(POSTMESSAGE,*, (fwddomain.S), (eia, *)) 

} we have Si(£>i).j'.scriptinputs|/? ^g S 2 (b 2 )-j.scriptinpnts \ p, and 

E. if 31 £ L such that l is a subterm of Si (bfj.j. scriptinputs, then S\(bi).j. location, dost = dri 
and S 2 (b 2 )-j-location.host = dr 2 , and 

F. \/k £ K: k is not contained in any subterm of Si(bi).j. scriptstate except for 

51 (£>i).y. script state. tagKey, and 

• Si(bi).y.origin ^ (dr\,S) 

=> k ^ Si (bi).j. scriptstate.tagKey, and 

• Si (bi).j. origin ^ (dri,S) 

=> k d®(Si(bi).j. scriptinputs), and 

• S 2 (b 2 ).j.origin ft (dr 2 ,S) 

=> k f S 2 (b 2 ).jscriptstate. tagKey, and 

• S 2 (b 2 ).j.origin f (dr 2 ,S) 

=> k ^ di/)(S 2 (b 2 ).j.scriptinputs), and 

v. if Si (bi).j. origin € {(dri , S), (dr 2 , S)} and Si(bi ).j. script f script_rp 22 then 

A. Si (bi).j. location and S 2 (£> 2 )-./-l° ca ' t ion are term-equivalent under 9 except for the host part, 
which is either equal or dri in b 1 and dr 2 in b 2 , and 

B. Si (bi).j. ref errer and S 2 (b 2 ).j .ref errer are term-equivalent under 9 except for the host part, 
which is either equal or dri in b 1 and dr 2 in b 2 , and 

C. Si(bi).j. scriptstate ^±g S 2 (b 2 ).j .scriptstate and if 31 £ L such that l is a subterm of 
Si (bi).j. scriptstate, then Si (b{).j. location.host = dr 1 and S 2 (b 2 )-j .location.host = dr 2 , 
and 

D. there is no k £ K such that k £ fl^AwdSi (^l)j-script state}) 
vi if Si (bi).j. origin = (fwddomain,S) then 

A. Si (Z?i). j. location ^±g S 2 (b 2 ).j-location, and 

B. Si(bi).j. scriptstate ^g S 2 (b 2 ).j .scriptstate, and 

C. for p = (POSTMESSAGE, *,*, (tagKey, *)) and X\ = Si (Z?i).y.scriptinputs| /2 and x 2 = 

5 2 (b 2 ).j .script inputs \p we have that for all i £ {1,..., |jt|}: 

22 It immediately follows that Si (b\).j. script = script_rp_redir in this case. 
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• 7T2(7r;(xi)) ^g 7T 2 (7T;(X2)), and 

• 7ri(7r 3 (7r ; -(xi))) ^ g or 

7 r i ( 7 r 3 ( 7 T/(x'i))) = dr\ A 7 Ti ( 7 r 3 ( 7 T,-(x 2 ))) = dr 2 , and 

• 7 T 2 ( 7 T 3 (tt/(^'i))) ^e and 

• 7r 4 (7r,-(xi)) ^g 7r 4 (7Ti(x2)), one/ 

vii. if Si (b\). j. origin ^ { (c/r i, S), (c/r 2 , S), (fwddomain, S)} f/zen 

A. Si(Zq). j. location ^(^-/location, and 

B. Si(bi).j.Teferrer^gS 2 (b 2 )-j-Teferrer, and 

C. Si(/i).j.scriptstate ^g S 2 (l> 2 )- j.scriptstate, and 

D. 5i(i>i).y.scriptinputs ;=±g ^(^-/scripbinputs, and 

E. there is no k £ K such that k £ dr^y^({Si (^l)- j- script state, Si(b\).j. script inputs}), and 

F. $1 £ L such that l is a subterm of Si (/?i).y.scriptstate or o/Si(Z?i)./scriptinputs, and 

(f for x £ {cookies, localStorage, sessionStorage, sts} we have that Si (Z?i).x ^g S 2 (p 2 )-x. For the do¬ 
mains dr 1 and dr 2 there are no entries in the subterms x. 

Definition 80 (Equivalence of Events). Let 6 be a set of proto-tags, L be a set of login session tokens, H be a set of 
nonces, and K := {k \ 3n : en c s ((y,n),k) € 9}. We call E\ = • • ■) an dE 2 = ...) /3-equivalent under 

(9 ,L,H) iff all of the following conditions are satisfied for every i £ N: 

1. One of the following conditions holds true: 

(a) f 1 ^g ef'* and if ep contains an HTTP(S) message (i.e., HTTP(S) request or HTTP(S) response), then the 
HTTP nonce of this HTTP(S) message is not contained in H, or 

(b) ' 1 is a DNS request from bi to dns/or dr\ and e^ 1 is a DNS request from b 2 to dns for dr 2 , or 

(c) e t ' 1 and ef ] are both DNS requests from any party except dns addressed to dns/or a domain unknown to the 
DNS server, or 

(d) f 1 is a DNS response from dns to bi for a DNS request for dr\ and ej 2) is a DNS response from dns to b 2 for 
a DNS request for dr 2 , or 

(e) f 1 is an HTTP request mi from bi to ri and e^ 1 is an HTTP request m 2 from b 2 to r 2 , m\ —g m 2 , and both 
requests are unencrypted or encrypted (i.e., mi and m 2 are the content of the encryption) and mi .nonce £ H, 
or 

(f) e t ' 1 is an HTTP(S) response from ri to bi and e\ ] is an HTTP(S) response from r 2 to b 2 , and their HTTP 
messages mi (contained in ) and m 2 (contained in ej 1 ') are the same except for the HTTP body gi := 
mi -body and the HTTP body g 2 ■= m 2 . body which have to be gi g 2 and m\ .nonce £ H and if gi contains 
a dictionary key loginSessionToken then there exists an l' £ L such that gi [loginSessionToken] = l'. 

2. If there exists l £ L such that l is a subterm of e \ 11 or ef^ then we have that e t ' 1 is a message from bi to ri and e\^ 
is a message from b 2 to r 2 or we have that is a message from ri to bi and ef^ is a message from r 2 to b 2 . 

3. If there exists k £ K such that k £ dy£\{i c y({e^\ef'^}) then ej 1 ' is an HTTP(S) response from rj to bi and e‘[^ is 
an HTTP(S) response from r 2 to b 2 and the bodies of both HTTP messages are of the form ((tagKey,£), *, *). 

4. If e j ^ or e [ \~ } is an encrypted HTTP response with body gfrom fwd, then 7r 4 (g) is script_f wd. 

5. If eor is an HTTP(S) response with body g from a relying party, then it does not contain any Location, 
Strict-Transport-Security or Set-Cookie header and iftti(g) is a string representing a script, then Tti(g) 
is either script_rp or script_rp_redir. 

6. Neither ej 1 ' nor ef' are DNS responses from dns for domains unknown to the DNS server. 

7. If e'P or e'f ’ is an unencrypted HTTP response, then the message was sent by some attacker. 

Definition 81 (Equivalence of Configurations). We call (Si,Ei,Ni) and (S 2 ,E 2 ,N 2 ) o-equivalent iff there exists a 
set of proto-tags 9 and a set of nonces H such that Si and S 2 are 7 -equivalent under (9,H), Ei and E 2 are /3-equivalent 
under (9,L,H) for L := (J ae0 loginSessionTokens(a,Si,S 2 ), and Ni = N 2 . 
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H.3 Privacy Proof 

Theorem 3. Every SPRESSO web system for privacy analysis is IdP-private. 

Let ST / US P "' = (W,S, script,£°, attacker) be an SPRESSO web system for privacy analysis. 

To prove Theorem 3, we have to show that the SPRESSO web systems STtfS p "' and STfS pm are indis¬ 
tinguishable (according to Definition 73), where STfS p "' and SIPS 1 !"' are defined as follows: Let $WS pn ' = 
(Tfi, S, script, £°, attacker) and $WS 2 "' = (S , script, Zs 0 , attacker) with/?] \=b(dri) £ and /72 := b{drf) £ Tf 2 
challenge browsers. Further, we require W\{bj = W\ \ {£»i} = ‘If 2 \ {^ 2 } • We denote the following processes in 
STfS p ' n as in Definition 72: 

dns denotes the honest DNS server, 

fwd denotes the honest forwarder with domain fwddomain, 
ri denotes the honest relying party with domain drj, and 
r 2 denotes the honest relying party with domain dr 2 . 

Following Definition 69, to show the indistinguishability of SWS P '" and SWS P "' we show that they are indistin¬ 
guishable under all schedules er. For this, we first note that for all cr, there is only one run induced by each a (as our 
web system, when scheduled, is deterministic). We now proceed to show that for all schedules a = (£ 1 , £ 2 , ■ • •), iff cr 
induces a run a(SWS p "' ) there exists a run a{S‘WS p "' ) such that a(STfS p ’ n ) ~ a(SWS p " v ). 

We now show that if two configurations are a-equivalent, then the view of the attacker is statically equivalent. 

Lemma 12. Let (S\,E\,N\) and ( S 2 ,E 2 ,N 2 ) be two a-equivalent configurations. Then Si (attacker) w S 2 (attacker). 

Proof From the a-equivalence of [S\,E\,N{) and (S 2 ,E 2l N 2 ) it follows that Si (attacker) ^g S 2 (attacker). From 
Condition 9 for 7 -equivalence it follows that {k \ 3n : en c s ((y,n),k) £ 0}nrf0((J/e{i.2}, AeWebUNet} ^(A)) the 
attacker does not know any keys for the tags contained in its view), and therefore it is easy to see that the views are 
statically equivalent. □ 

We now show that a(STfS pm ) ~ a(STfS p "') by induction over the length of a. We first, in Lemma 13, show that a- 
equivalence (and therefore, indistinguishability of the views of attacker) holds for the initial configurations of SWS P "' 
and STfS pn ' . We then, in Lemma 14, show that for each configuration induced by a processing step in £, a-equivalence 
still holds true. 

Lemma 13. The initial configurations (S®,E°,N°) of SWS P "' and (S®,E°,N°) of SWS^" ar e a-equivalent. 

Proof. We now have to show that there exists a set of proto-tags 6 and a set of nonces H such that .S ’) 1 
and S® are 7 -equivalent under (0.11), E® = E° and E® = E° are /3-equivalent under (O.L.II) with L := 

(J c ,e8 loginSessionTokens(a,Si,S 2 ), an d N® = =N°. 

Let 0 = H = L = 0. Obviously, both latter conditions are true. For all parties p £ ‘W\ \ {b\ }, it is clear that S®(p) = 
Sj(p). Also the states S®(b 1 ) and S^iho) are equal. Therefore, all conditions of Definition 79 are fulfilled. Hence, the 
initial configurations are a-equivalent. □ 

Lemma 14. Let (S\, E\ ,N\) and (5’2, £2 ,W) be two a-equivalent configurations of SWS P "' and SkVS pn ', respectively. 
Let <C = (ci,cp,Tp Wcess ,cmd sw itch,cmd w i n dow,T SC ript,url) be a web system command. Then, £ induces a processing step 
in either both configurations or in none. In the latter case, let (S\,E[,N’f) and (S^E^Nf) be configurations induced 
by £ such that 

(S\,E\,N\) -4 (S' , 1 ,£j,/V{) and (S 2 ,E 2 ,N 2 ) 4 {S^E^N'z) . 

Then, (S\,E[,N[) and (S^E^N'f) are a-equivalent. 

Proof. Let 9 be a set of proto-tags and H be a set of nonces for which a-equivalence of (S\ .E\,N\) and ( S 2 ,E 2 l N 2 ) 
holds and let L := \J aee loginSessionTokens(a,Si ,S 2 ), K := {k \3n : enc s ((y,n),k) £ 9}. 

To induce a processing step, the ci'-th message from E\ or E 2 , respectively, is selected. Following Definition 80, we 
denote these messages by e \ 1! or e\~\ respectively. We now differentiate between the receivers of the messages. 
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We first note that due to the o-cquivalence, £ either induces a processing step in both configurations or in none. We 
have to analyze the conditions stated in Corollary 1 : The number of waiting events is the same in both configurations, 
and therefore, (ci > |£) |) <=> (ci > \E 2 \). Further, the set of processes is the same (except for the browsers, which 
are exchanged but have the same IP addresses). Also, we have no processes that share IP addresses within each system. 
Therefore, if cp ^ 1 then it refers to no process in both runs (and no processing step can be induced). As we show 
below, if e ) 1 ' is delivered to h\ then and only then ef ' 1 is delivered to h 2 . Additionally, the window structure in both 
browsers is the same, and therefore, (:iiid wlm i ow either refers to a window that exists in both configurations or in none. 
There are no other cases that induce no processing step in either system. 

We denote the induced processing steps by 


(S U E u Ni) Aj) and 

P 

(s 2 ,e 2 ,n 2 ) {a2j2 ’ m2) ^ p - 2 > (, s' 2 ,e' 2 ,n' 2 ) . 


Case p\ = fwd: We know that one of the cases of Case 1 of Definition 80 must apply for ej 1: and ef' ! . Out of these 
cases only Case la applies. Hence, p 2 = fwd. 

In the forwarder relation (Algorithm 11), either Lines 9f. are executed in both processing steps or in none. It is easy 
to see that E^ ^g E^ t (containing at most one event). For this new event all cases of Definition 80 except for Cases 2 
and 1 hold trivially true. 

(*): As both events are static except for IP addresses, the HTTP nonce, and the HTTPS key, there is no k contained in 
the input messages or in the state of fwd (except potentially in tags, from where it cannot be extracted), and the output 
messages are sent to f\ or f 2 , respectively, they cannot contain any / £ L or k € K. Hence, Case 2 of Definition 80 holds 
true. 

Both output events are constructed exactly the same out of their respective input events and Case la applies for the 
output events. 

Therefore, E[ and E' 2 are /3-equivalent under {().ILL). As there are no changes to any state, we have that S\ and S' 2 
are 7 -equivalent under (0. H). No new nonces are chosen, hence, N\ = N[ = N 2 = N 2 . 

Case pi = dns: In this case, only Cases la, lb and lc of Definition 80 can apply. Hence, p 2 = dns. We note that (*) 
applies analogously in all cases. 

In the first case, it is easy to see that E^ t E^j. In the second case, it is easy to see that the DNS server only 
outputs empty events in both processing steps. In the third case, E^j and are such that Case Id of Definition 80 
applies. 

Therefore, E[ and E 2 are /3-equivalent under (0.ILL) in all three cases. As there are no changes to any state in all 
cases, we have that S[ and S 2 are 7 -equivalent under (0. //). No new nonces are chosen, hence, N\ =N[ =N 2 =N 2 . 
Case p\ = ri: First, we consider cases that can never happen or are ignored in both processing steps. After this, we 
distinct several cases of HTTPS requests. 

If e (l , : ' is a DNS response, we know that <7 1 ;=±g e\\ which implies p 2 = ri. Only DNS responses from dns are 
processed by a relying party, other DNS responses are dropped without any state change. As the state of a relying party 
fulfills Condition 6 of Definition 79 (RPs only query domains unknown to d ns) and both ej 1 * and e f 1 fulfill Condition 6 
of Definition 80 (there are no DNS responses from dns about domains unknown to dns), we have a contradiction. 
Hence, ej 1 ^ cannot be a DNS response. 

If e ' 1; is an HTTP response, we know that ep ^g e\~\ which implies p 2 = ri. From Condition 7 of Definition 79, 
we know that relying parties always drop HTTP responses (without any state change). 

If ej 1 '* is any other message that is not a (properly) encrypted HTTP request, we have that e) 1 ^ ^±g e\"\ which implies 
p 2 = f\. The relying party drops such messages in both processing steps (without any state change). 

For the following, we note that a relying party never sends unencrypted HTTP responses. 

There are four possible types of HTTP requests that are accepted by r\ in Algorithm 9: 

• path = / (index page). Line 28, 
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• path = /startLogin (start a login). Line 31, 

• path = /redir (redirect to IdP), Line 43, and 

• path = /login (login). Line 53. 

From the cases in Definition 80, only two can possibly apply here: Case la and Case le. For both cases, we will now 
analyze each of the HTTP requests listed above separately. 

Definition 80, Case la: e\ 1 1 efi'. This case implies pi = t\ = p\. As we see below, for the output events and 

(2) 

£o“t (if any) only Case la of Definition 80 applies. This implies that the output events may not contain any HTTP 
nonce contained in H. As we know that the HTTP nonce of the incoming HTTP requests is not contained in H and the 
output HTTP responses (if any) of the RP reuses the same HTTP nonce, the nonce of the HTTP responses cannot be in 

H. 

• path = /. In this case, the same output event is produced, i.e. //,'/ = , and Condition 5 of Definition 80 

holds true. Also, (*) applies. The remaining conditions are trivially fulfilled and E[ and E' 2 are /3-equivalent under 
(0,//,L). As there are no changes to any state, we have that S[ and S' 2 are 7 -equivalent under ((/.//). No new 
nonces are chosen, hence, N\ =N[ = N 2 = N 2 . 

• path = /startLogin. The domains of the email addresses in both message bodies are either equivalent and 
registered to the DNS server (and hence, wkCache contains a public key for this domain), or they are not contained 
in wkCache (in both, 5i(n) and 52 (n))- If they are unknown (i.e., not contained in wkCache), they are not 
registered in the DNS server. Nonetheless, in this case a DNS request is sent to dns. Then, the terms //>'/ and 
E^l contain a request matching Case la of Definition 80. As L/,, 1 ,, and e{~J are constructed such that besides IP 
addresses, a string, and a nonce, they only contain a term derived from the input events. In particular, they contain 
no k £ K or / € L (**): As Condition 2 of Definition 80 applies for the input events, this condition also applies 
for the output events. Thus, E[ and E 2 are /3-equivalent under (0. H. L). The states S\ (r\) is equal to 5 1 (r 1 ) up to 
the subterm pendingDNS, and S 2 (r \) is equal to 52 (n) up to the subterm pendingDNS. The subterm pendingDNS 
only contains a new entry for a domain unknown to the DNS server. Hence, Condition 6 of Definition 79 holds. 
Thus, we have that S\ and S, are 7 -equivalent under (0. // ). Exactly one nonce is chosen in both processing steps, 
and therefore N[ = N 2 . 

If the domains of the email addresses are valid and registered in wkCache, then SENDSTARTLOGINRESPONSE 
is called. In both processing steps, a tag is constructed exactly the same. The same HTTP response (which does not 
contain a k £ K or a / £ L) is put in both //>'/ and Lout - The first element of the response’s body is not a string and 
therefore Condition 5 holds true. The tag is only created on r\ in both runs and hence, 0 does not have to be altered. 
Analogously to (**) we have that E[ and E 2 are /3-equivalent under (0,II.L). The subterm loginSessions of 
the state of r\ is extended exactly the same. Thus, we have that S\ and S 2 are 7 -equivalent under (0, II). In both 
processing steps exactly four nonces are chosen, and we have that N[ =N 2 . 

• path = /redir. First, we note that there is no / £ L contained in either m\ or m 2 (by the Defintion of /3-equivalence). 
We further note that a relying party that receives an (encrypted) HTTP request for the path /redir either (I) stops 
in Line 46 of Algorithm 9 with an empty output or (II) emits an HTTP response in Line 52. The state of the relying 
party is not changed in either case. 

We now show that in both processing steps always the same cases apply. For i £ {1,2} and body i the body of the 
HTTPS request m,-, Case (II) applies for r\ iff 

5,(ri).loginSessions/?ody ; [loginSessionToken]] ^ () 

(see Lines 44 ff. of Algorithm 9). 

From Condition 5 of Definition 79, we know that 52 (^ 1 ).loginSessions can be constructed from 
5i (ri).loginSessions without removing the entry with the dictionary key body l [loginSessionToken] 
(as this key is not in L). Thus, both dictionaries either contain the same entry for the dictionary key 
body! [loginSessionToken] or they both contain no such entry. Hence, Case (II) applies in both processing 
steps or in none. 

In both cases, exactly the same outputs are emitted (without containing any / £ L or k £ K) and no state is changed 
and no new nonces are chosen. In both cases, the first element of the response body (if any) is script_rp_redir. 
We therefore trivially have o-equivalence of the new configurations. 


64 


• path = /login. This case can be handled analogously to the previous case with two exceptions: 

(A) First, there are two additional checks, the first in Line 54 of Algorithm 9 and the second in Line 64. We have 
to show that both checks each either simultaneously succeed or fail in both cases. 

For the first check, it is easy to see that this follows from m\ ^g m 2 . 

As we have that m\ ^ g m 2 , and in particular eia\ := body 1 [eia] ^g body 2 [e ia] =: eia 2 , both, eia\ and eia 2 have 
the same structure. If this structure does not match the expected structure (see Line 62f.), the checks in both 
processing steps fail. 

If r 1 accepts the identity assertion, then we have that the tag, the email address and the forwarder domain must be 
equal in m \ and m 2 as 


Si (ri). loginSessions [/wtfyi [loginSessionToken]] 

= S2(n).loginSessions[/?o</y2[loginSessionToken]] ■ 

Hence, r\ either accepts in both processing steps or in none. 

(B) If r\ accepts, i.e., it does not stop with an empty message, then r 2 accepts. A nonce is chosen exactly the same 
in both processing steps. Hence, we have that N[ = N 2 . 

Definition 80, Case le: ef 1 is an HTTP(S) request from b\ to r\ and e'f' ! is an HTTP(S) request from b 2 to r 2 . This 
case implies p 2 = r 2 . 

We note that Condition 5 of Definition 80 holds for the same reasons as in the previous case. As the response is 
always addressed to the IP address of b\ or b 2 , respectively. Condition 5 of Definition 80 is fulfilled. 

As we see below, for the output events Lou, and (if any) only Case If of Definition 80 applies. This implies that 
the output events must contain an HTTP nonce contained in H. As we know that the HTTP nonce of the incoming 
HTTP requests is contained in H and the output HTTP responses (if any) of the RP reuses the same HTTP nonce, the 
nonce of the HTTP responses is in H. 

• path = /. In this case, the output events produced (containing no / 7 L or k 7 K result in E[ and £,/ being /3- 
equivalent under if),II.L) according to Definition 80, Case If. As there are no changes to any state, we have that 
S[ and Si, are 7 -equivalent under {(). // J. No new nonces are chosen, hence, N\ = N[ = N 2 = Nf 

• path = /startLogin. As above, both email addresses in the input events either equivalent and their domain is 
known to the relying parties, or both email address domains are unknown. The latter case is analogue to above. 
Otherwise, wkCache, then SENDSTARTLOGINRESPONSE is called. In both processing steps, a tag is con¬ 
structed the same up to the RP domain dr\ or dr 2 , respectively. 

In both processing steps, an HTTP response is created. We denote the HTTP response generated by r\ as m\ and 
the one generated by r 2 as m' 2 . We then have that 

m[ = enc s ((HTTPResp,«,200, (),gi),k) 
m' 2 = enc s ((HTTPResp,n,200, {),g 2 ),k) 


with 


gi = ((tagKey, v 2 ), (loginSessionToken, of), (FWDDomain,Si (ri).FWDDomain)) 
g 2 = ((tagKey, v 2 ), (loginSessionToken, of), (FWDDomain,S 2 (r 2 ).FWDDomain)} 

Obviously, m\ equals mi,. For N\ =N 2 = (n \,n 2 ,.. . ), we set O' = 6 U {enc s ((y,ni),« 2 )}, N(=N 2 = (ns,...) (as 
exactly four nonces are chosen in both processing steps), and L' = LU { 14 }. The receiver of both messages is the 
browser b\ or b 2 , respectively. Obviously, it holds that L' = (J a ee' loginSessionTokens(a,5' , 1 ,S 2 ) and there exists 
an l' £ if such that g 1 [loginSessionToken] = if As Conditions If and 3 of Definition 80 hold, E( and E 2 are 
/3-equivalent under (O' The subterm loginSessions of Si ( 77 ) is extended exactly the same as the subterm 
loginSessions of S 2 (r 2 ). Thus, we have that S\ and S( are 7 -equivalent under (O' ,H). (As mentioned above, in 
both processing steps exactly four nonces are chosen, and we have that N( = Nf) 
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• path = /redir. By the definition of /3-equivalence, the login session token l is the same. By the definition of 
7 -equivalence, we have that Algorithm 9 either (I) stops in both processing steps in Line 46 with an empty output 
or (II) (if I £ L ) emits an HTTP response in both processing steps in Line 52. 

From Condition 5 of Definition 79 we know that for ls\ := .S'| (77 ).loginSessions[/] and Is 2 := 
5 , 2 (r 2 ).loginSessions[/] we have that ls\ ^g ls 2 - 

We denote the HTTP response generated by r i as m\ and the one generated by 77 as m' 2 . We then have that 

m[ = enc s ((HTTPResp,n,200, (),gi),k) 
m 2 = enc s ((HTTPResp,n,200, (},g 2 ),k) 


with 


gi = (script_rp_redir, (URL, S, domain 1 , /.well-known/spresso-login.paraOTij)) 
g 2 = (script_rp_redir, (URL, S,domain, /.well-known/spresso-login.para/H^)) 

and domain 1, domain2, params l , params 2 derived exactly the same from Is\ and ls 2 , respectively (and neither 
paramsi nor params 2 contains a key loginSessionToken). No keys k £ K are contained in the output. Thus, the 
output events fulfill Condition If of Definition 80. 

No state is changed and no new nonces are chosen. We therefore have o-cquivalcnce of the new configurations. 

• path = /login. 

This case can be handled analogously to the previous case with two exceptions: 

(A) First, there are two additional checks, the first in Line 54 of Algorithm 9 checks the origin header and the 
second in Line 64 checks the identity assertion. 

As we know that m\ —g m 2 , we have that if the first check fails in 77 then and only then it fails in 77 • The same 
holds true for the second check. 

If r\ accepts the identity assertion, then we have that the email address must be equal in ni\ and m 2 as 

(ri).loginSessions[i>ot/V] [loginSessionToken]] 

= S 2 (n)-loginSess ions [body 2 [loginSessionToken]] . 

and we have that the identity assertion in gi is valid for 77 , i.e., signed correctly and contains a tag for dr\ , and 
thus, the identity assertion in g 2 is valid for 77 . Hence, 77 and 77 either accept in both processing steps or in none. 

(B) If r 1 accepts, i.e., it does not stop with an empty message, we know that 77 accepts. A nonce is chosen exactly 
the same in both processing steps. Hence, we have that N[ = /V(. 

Case p\ - 7 .' This case is analogue to the case p \ = ri above. Note that the Case le of Definition 80 cannot occur by 
definition. 

Case pi = bi.• =>■ p 2 = b 2 

We now do a case distinction over the types of messages a browser can receive. 

DNS response For the input events either Condition la of Definition 80 or Condition Id apply. Therefore, the DNS 
request/response nonces in both events are equivalent up to RP domains under a set of proto-tags 9. From Condi¬ 
tion 12b of Definition 79, we know that for a given nonce, there is either an entry in the dictionary pendingDNS 
in both browsers or in none. There are no entries under keys that are not nonces. Hence, both browsers either 
continue processing the incoming DNS response or stop with no state change and no output events in Line 55 of 
Algorithm 7. Further, we note that the resolved address contained in the DNS response has to be an IP address. 
From Condition 12b of Definition 79, we know that the protocol in both stored HTTP requests is the same. 
Therefore, the browsers either both choose a nonce (for HTTPS request) or none. 

There can now be two cases: (I) The IP addresses in both DNS responses are the same or (II) the IP address in 
77(1 is an IP address of 77 and the IP address in mo is an IP address of 7 - 2 - In both cases, the pending requests of 
the respective browsers are amended in such a way that they fulfill Condition 12c (as they fulfilled Condition 12b, 
which is essentially the same for HTTP(s) requests). 
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For Eg*} and E^(, we have that in Case (I) E^ t and hence Condition la of Definition 80 is fulfilled. In 

Case (II), the output messages fulfill Condition le. 

From Condition 2 of Definition 80, we know that no l £ L is contained in the DNS responses. Further, we know 
from Condition Id of Definition 80 that if the IP addresses in the DNS responses differ, then they are responses for 
dr\ and dr 2 , respectively. From Condition 12b of Definition 79, we know that only requests (prepared) for dr \ and 
dr 2 , respectively, may contain a subterm 1 £ L. Hence, Condition 2 of Definition 79 holds true. 

We also have that no k £ K is contained in the response (with Condition 3 of Definition 79). There is also no k £ K 
contained in the browser’s pending HTTP requests, and therefore, there is none in the output events. 

We have that S[ and S' 2 are 7 -equivalent under {(), 11 ), E[ and E' 2 are /3-equivalent under ((). II. L), N[ = N 2 , and 
thus, the new configurations are o-equivalent. 

HTTP response In this case, it is clear that the HTTP(s) response nonce, which has to match the nonce in the browser’s 
pendingRequests, is either the same in both messages m\ and m 2 or it contains a tag. If it contains a tag (with 
Condition 12c of Definition 79) or if it contains a nonce that is not in pendingRequests (which contains the same 
nonces for both browsers), both browsers stop and do not output anything or change their state. 

We can now distinguish between two cases: In both browsers, (I) the reference that is stored along with the HTTP 
nonce is a window reference (in this case, the request was a “normal” HTTP(S) request), or (II) this reference is a 
pairing of a document nonce and an XHR reference chosen by the script that sent the request, which is an XHR. 
From Condition 12c of Definition 79 it is easy to see that no other cases are possible (in particular, the reference in 
both browsers is the same). 

(I) In Case (I), we can distinguish between the following two cases: 

(a) The HTTP nonce in m\ is in H : In this case, only Case If of Definition 80 can apply. We therefore have 
that there is no Location, Set-Cookie or Strict-Transport-Security header in the response, and that the 
responses mi and m 2 are equal up to proto-tags in 9. From Case 12c of Definition 79 we have that in 
both browsers b\ and b 2 the encryption keys stored in pendingRequests are the same, that the expected 
sender in e- is r\ and in ej 2 is r 2 . 

With this, we observe that both browsers either accept and successfully decrypt the messages and call 
the function PROCESSRESPONSE, or both browsers stop with not state change and no output event (in 
which case the a-cquivalence is given trivially). In particular we note that the expected sender in both 
cases matches precisely the sender the message has (compare Case If of Definition 80). 

In PROCESSRESPONSE, we see that no changes in the browsers’ cookies are performed (as no cookies 
are in the response), the sts subterm is not changed, and no redirection is performed (as no Location 
header is present). 

Now, new documents are created in each browser. These have the form 

(z/ 7 , location, referrer, script, scriptstate ,(),(), T) 


with 


location = (URL,protocol, host,path,parameters) . 


Here, script, scriptstate are the same and protocol, path, parameters are taken from the requests, which 
means that these subterms are equal or term-equivalent up to proto-tags 9 according to Case 12c of 
Definition 79. The host and the referrer are the same in both states up to exchange of domains, which can 
be dr\ in b\ and dr 2 in b 2 . 

We note that if k £ K, then the request will not be of the correct form to be parsed into a document in the 
browser, and both browsers stop with an empty output and no state change. 

The browser now attaches these newly created documents to its window tree, and we have to check that 
the Condition 12e of Definition 79 is satisfied. 

As we have that both incoming messages were encrypted messages (see Case 7 of Definition 80) 
and both messages come from r\ and r 2 , respectively, and therefore script is either script_rp or 
script_rp_redir (see Case 5 of Definition 80) we have to check Conditions 12(e)iv and 12(e)v of 
Definition 79 in particular. 

The scriptstate is initially equal and may contain a subterm l £ L (as we know from HTTP nonce in m\ 
being in H that the host of this document is dr\ in b\ and dr 2 in b 2 ), and the script inputs are empty. The 
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document’s referer is constructed from the referer header of the request, which is equal in both cases or 
has the host dr\ in b\ and dri in Z? 2 - 

To sum up, 7 -equivalence under ( 8,H ) is preserved, a-equivalence is preserved as no output event is 
generated and the exact same number of nonces are chosen. 

(b) The HTTP nonce in mi is not in H: In this case we have that =7 ef ] (Case la of Definition 80), and 
that the HTTP nonces, senders, encryption keys (if any) and original requests in the pending requests of 
both browsers are either equal or equivalent up to proto-tags 8. There can be no k £ K as a subterm (except 
in tags) of the input. 

With this, we observe that both browsers either accept and successfully decrypt the messages and call 
the function PROCESSRESPONSE, or both browsers stop with no state change and no output event (in 
which case the a-equivalence is given trivially). In particular we note that the expected sender in both 
cases matches precisely the sender of the message (as it is equal). 

If there is a Set-Cookie header in one of the responses, a new entry in the cookies of each browsers is 
created (which obviously is term-equivalent up to 0, and therefore is in compliance with the requirements 
for 7 -equivalence). The same holds true for any Strict-Transport-Security headers. 

Now, if there is a Location header in m\ (and therefore also in m 2 ), a new request is generated and stored 
under the pending DNS requests, and a DNS request is sent out. The new HTTP(S) requests contains the 
method, body, and Origin header of the original request (which were equivalent up to proto-tags 8), where 
the Origin header is amended by the host and protocol of the original request. 

Also, we know from ep <7 2 that neither event may contain a subterm / £ L or k € K. Hence, the 
transferred (initial) scriptstate (or a request generated by a Location header, see below) cannot contain a 
subterm l £ L or k € K. 

Now, assuming that the domain in the Location header was not CHALLENGE, then the new request is 
term-equivalent under 8 between both browsers. A new DNS request is generated (which conforms to 
Condition la of Definition 79). It is sent out and the HTTP request is stored in the pending DNS requests 
of each browser. It is clear that in this case, the conditions for 7 -equivalence under ( 8,H ) (in particular. 
Condition 12b) and /^-equivalence under ( 8,H,L ) are satisfied. The same number of nonces is chosen. 
Altogether, a-equivalence is given. 

If, however, the domain is CHALLENGE (and the browser has not started a request to CHALLENGE before; in 
this case the browser would behave as above), then the domain is dr\ in b\ and dri in /? 2 - In particular, in 
the resulting requests, the Host header is exchanged in this way. For alpha equivalence to hold for the new 
configuration, we have H' = HU {/;}, where n is the nonce chosen for the HTTP(S) request. A new DNS 
request is generated (which in this case conforms to Condition lb of Definition 79). Therefore, we have 
7 -equivalence under ( 8,H') and /3-equivalence under (8,H',L). The same number of nonces is chosen, 
and we indeed have a-equivalence. 

If there is no Location header in m\ (and therefore none in m 2 ), a new document is constructed just as in 
the case when the nonce in m\ is in H. 

The scriptstate is initially equal, and the script inputs are empty. The document’s referer is constructed 
from the referer header of the request, which is equal in both cases (up to proto-tags in 8 ). 

To sum up, 7 -equivalence under ( 8,H ) is preserved in this case as well, a-equivalence is preserved as no 
output event is generated and the exact same number of nonces are chosen. 

(II) In Case (II), i.e., the response is a response to an XHR, we have that reference is a tupel, say, reference = 
(docnonce ,xhrref), and we again distinguish between the two cases as above: 

(a) The HTTP nonce in m\ is in H: In this case, only Case If of Definition 80 can apply. We therefore have 
that there is no Location, Set-Cookie or Strict-Transport-Security header in the response, and that the 
responses m\ and m 2 are equal up to proto-tags in 8. From Case 12c of Definition 79 we have that in both 
browsers b\ and b 2 the encryption keys stored in pendingRequests are the same and that the expected 
sender in e^ ! is r\ and in ej 2 ' 1 is r 2 - 

With this, we observe that both browsers either accept and successfully decrypt the messages and call 
the function PROCESSRESPONSE, or both browsers stop with not state change and no output event (in 
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which case the a-equivalence is given trivially). In particular we note that the expected sender in both 
cases matches precisely the sender of the message (compare Case If of Definition 80). 

In PROCESSRESPONSE, we see that no changes in the browsers’ cookies are performed (as no cookies 
are in the response), the sts subterm is not changed, and no redirection is performed (as no Location 
header is present). 

A new input is constructed for the document that is identified by docnonce. We note that such a document 
exists either in both browsers or in none (in which, again, both browsers stop with no output or state 
change). As the input events may contain a subterm l £ L( as we know from HTTP nonce in m\ being in 
H that the host of this document is dr\ in b\ and dri in £> 2 ). the constructed scriptinput may also contain a 
subterm l £ L. The same holds true for keys k £ K. 

For j £ {1,2}, we have that the scriptinput term for the document in bj is 
(XMLHTTPREQUEST,g ; '.body,r/!rre/), where gj is the HTTP body of nij. With gi ^ g g2 and 
xhrref £ 5\£u{_L}, it is easy to see that the resulting scriptinput term of the document is 
term-equivalent under proto-tags 0 (as it was before). This satisfies 7 -equivalence on the new browser 
state. 

No output event is generated, and no nonces are chosen. Therefore we have a-equivalence on the new 
configuration. 

(b) The HTTP nonce in m\ is not in H: In this case we have that e ;=7 e\ ] (Case la of Definition 80), and 
that the HTTP nonces, senders, encryption keys (if any) and original requests in the pending requests of 
both browsers are either equal or equivalent up to proto-tags 0 . 

With this, we observe that both browsers either accept and successfully decrypt the messages and call 
the function PROCESSRESPONSE, or both browsers stop with not state change and no output event (in 
which case the a-equivalence is given trivially). In particular we note that the expected sender in both 
cases matches precisely the sender the message has (as it is equal). 

If there is a Set-Cookie header in one of the responses, a new entry in the cookies of each browsers is 
created (which obviously is term-equivalent up to 9, and therefore is in compliance with the requirements 
for 7 -equivalence). The same holds true for any Strict-Transport-Security headers. 

Now, if there is a Location header in m\ (and therefore also in m 2 ), both browsers stop with not state change 
and no output event (in which case the a-equivalence is given trivially), as XHR cannot be redirected in 
the browser. 

If there is no Location header in mi (and therefore none in m 2 ), a new input is constmcted for the document 
that is identified by docnonce. We note that such a document exists either in both browsers or in none. For 
j £ {1,2}, we have that the scriptinput for the document in bj is (XMLHTTPREQUEST,gpbody,x/irre/), 

where gj is the HTTP body of nij. With e) 1 ] =7 ef ! (which may not contain a subterm l £ Lor k £ K), it 
is easy to see that the resulting scriptinput term of the document is term-equivalent under proto-tags 9 
(as it was before). This satisfies 7 -equivalence on the new browser state. 

No output event is generated, and no nonces are chosen. Therefore we have a-equivalence on the new 
configuration. 

TRIGGER We now distinguish between the possible values for and swll ch- 

1 (trigger script): In this case, the script in the window indexed by cmd wm( i mv is triggered. Let j be a pointer to 
that window. 

We first note that such a window exists in b\ iff it exists in hi and that ,S’| (b\ ). /.script = .SV/^)../.script. 
We now distinguish between the following cases, which cover all possible states of the windows/documents: 

1. S\(bi).j. origin £ {(dr i,S), (t/r 2 ,S)} and Si(bi).j. script = script_rp. 

Similar to the following scripts, the main distinction in this script is between the script’s internal states 
(named q). With the term-equivalence under proto-tags 6 we have that either Si (iq).}.scriptstate.q = 
.S - 2 (/? 2 )■{'scriptstate.q or the script’s state contains a tag and is therefore in an illegal state (in which 
case the script will stop without producing output or changing its state). 

We can therefore now distinguish between the possible values of .S’] (b\ )./.scriptstate.q = 
S 2 (fe) J.scr ipt state, q: 
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start: In this case, the script chooses one nonce in both processing steps and creates an XHR addressed 
to its own origin, which is in both cases either (a) equal and (dr\ , S) or (dr 2 ,S) or it is (b) (dr\, S) in 
b\ and ( dr 2 ,S ) in b 2 . The path is the (static) string /startLogin. The script saves the freshly chosen 
nonce (referencing the XHR) and a (static) value for q in its scriptstate. We note that if a k £ K is 
contained in the script’s state, it is never sent out in this state. 

In Case (a), we have that the command is term-equivalent under proto-tags 6 and hence, the browser 
emits a DNS request which is term-equivalent, and appends the XHR in pendingDNS. Hence, we 
have 7 -equivalence under (9, El) for the new states, /^-equivalence under (0.It .L) for the new events, 
and o-cquivalence for the new configuration. 

In Case (b), we have that the prepared HTTP request is ^-equivalent under 9, and is added to 
pendingDNS in the browser’s state, we set H 1 := H U { n } with n being the nonce that the browser 
chooses for Ai. The browser emits a DNS request that fulfills Condition lb of Definition 80. Therefore, 
we have 7 -equivalence under ( 9,H ') for the new states. As the request added to pendingDNS in the 
browser’s state fulfills Condition 12b, we have /3-equivalence under (9,Et' ,L) for the new events, and 
a- equivalence for the new configuration. 

expectstartLoginResponse: In this case, the script retrieves the result of an XHR from scriptinputs that 
matches the reference contained in scriptstate. From Condition 12(e)iv of Definition 79 we know that 
all results from XHRs in scriptinput are term-equivalent up to 9 and that scriptstate is term-equivalent 
up to 9. Hence, in both browsers, both scripts stop with an empty command or both continue as they 
successfully retrieved such an XHR. 

Now, a URL is constructed (exactly the same) for an (HTTPS) origin that is the origin of the document. 
We have to distinguish between to cases: Either the origin is (i) equal in b\ and hi. or (ii) the origin 
is (dr 1 , S) in h\ and (dri. S) in bi. In the first case (i), no subterm 1 S L is contained in scriptinput 
and hence, no such subterm is contained in the constructed URL. In the second case (ii), however, we 
have that such a subterm may be contained in scriptinput. But as the URL commands the browser 
to prepare a request to dr\ and dr 2 , respectively, the request may be stored in pendingDNS of the 
browser’s state. 

To store the prepared HTTP request in pendingDNS, the browser chooses a nonce n. We construct 
the set H' as follows: In (i) H' := H and in (ii) //':=// U {/;}. Thus, Condition 12b of Definition 79 
holds true under (9,El'). 

In Case (i) we also have that no k £ K is written into scriptstate.tagKey. Otherwise, a k £ K may 
be written there. In no case, a k £ K is contained in the output event or generated HTTP request (as 
scriptstate.tagKey is not used to create such event or request). 

The output events of both browsers are either a DNS request that is equal in (i) or a DNS request that 
matches Condition lb of Definition 80. 

We now have that S’; and are 7 -equivalent under ( 9,H'),E[ and £3, are /3-equivalent under (9,H',L), 
and as exactly the same number of nonces is chosen, we have that the new configuration is a- 
equivalent. 

expectFWDReady: In this case, the script retrieves the result of a postMessage from scriptinputs. As we 
know that S\ (b\).j. script state ^g S 2 (bo )-j. script state and that for all matching postMessages 
that they also have to be term-equivalent up to 9 and that the window structure is equal in both browsers, 
we have that either the same postMessage is retrieved from scriptinputs or none in both browsers. 
The script now constructs a postMessage that is sent to exactly the same window in both browsers and 
that requires that the receiver origin has to be (f wddomain, S) The postMessage is only sent to this 
origin, we have that 7 -equivalence cannot be violated even if a k £ K is contained in the postMessage 
(as there are no constraints concerning K in the script inputs of this origin). 

We now have that S\ and S' 2 are 7 -equivalent under (9,H), E[ and E( are /3-equivalent under (9,H,L), 
and as exactly the same number of nonces is chosen, we have that the new configuration is a- 
equivalent. 

expectEIA: In this case, the script retrieves the result of a postMessage from scriptinputs. As we know 
that Si(bi).j. scriptstate 2 =±g ^(^j-i-scriptstate and that for all matching postMessages that 
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they also have to be term-equivalent up to 9 and that the window structure is equal in both browsers, 
we have that either the same postMessage is retrieved from scriptinputs or none in both browsers. 
The script chooses one nonce in both processing steps and creates an XHR addressed to its own origin, 
which is in both cases either (a) equal and (dr \, S) or ( midr 2 , S) or it is (b) {dr \, S) in b\ and (. midr2 , S) 
in Z? 2 - The path is the (static) string /login. The script saves the freshly chosen nonce (referencing 
the XHR) and a (static) value for q in its scriptstate. 

In Case (a), we have that the command is term-equivalent under proto-tags 9 and hence, the browser 
emits a DNS request which is term-equivalent, and appends the XHR in pendingDNS. Hence, we 
have 7 -equivalence under (9,H) for the new states, /^-equivalence under (0.H.L) for the new events, 
and a-equivalence for the new configuration. 

For Case (b), we note that for j £ {1,2}, the body gj of the prepared HTTP request may contain an 
(encrypted) identity assertion such that 

gj[eia] ~ enc s (sig((enc s ((£/r ; ',*),*),*,fwddomaiii),*),*). 

As the receiver of this message is always determined to be drj (in b f) and the Origin header is set 
accordingly, we have that the prepared HTTP request is 5-equivalent under 0. The (prepared) request 
is added to pendingDNS in the browser’s state, we set H' := // U {n } with n being the nonce that the 
browser chooses for Ai. The browser emits a DNS request that fulfills Condition lb of Definition 80. 
In no case is a k £ K, which can only be stored in scriptstate.tagKey used to construct either 
output events or state changes. Therefore, we have 7 -equivalence under ( 9,H') for the new states. As 
the request added to pendingDNS in the browser’s state fulfills Condition 12b, we have /3-equivalence 
under (9,H',L) for the new events, and o-equivalence for the new configuration. 

2. Si(b\).j. origin £ {(dri,S),(dr 2 ,S)j and Si {b\).j. script ^ script_rp. It immediately follows that 
S\(b\).j. script = script_rp_redir in this case. This script always outputs the same command to 
the browser: it commands to navigate its window to a URL saved as the script’s scriptstate, which is 
term-equivalent under proto-tags between the two browsers. As the HTTP request that is generated (and 
then stored in pendingDNS) contains neither an Origin nor a Referer header, they are term-equivalent 
under 9 if the domain of this HTTP request is not CHALLENGE 23 and 5-equivalent otherwise. 

The resulting states of both browsers are therefore 7 -equivalent under 9. 

In both cases (challenged or not), we have that ;= 7 y and hence Condition la of Definition 80 is 
fulfilled, or the output messages fulfill Condition le. 

Clearly, no k £ K is contained in the script’s state, in the generated DNS request, or the HTTP request. 

In both processing steps, exactly the same number of nonces is chosen. We therefore have a-equivalence. 

3. Si(b\).j. origin = (fwddomain,S). 

It immediately follows that S\(b\).j. script = script_fwd in this case. 

As above, we have that either S\(b\).j. scriptstate.q = /> 2 (£’ 2 )-./-scriptstate.q or the script’s state 
contains a tag and is therefore in an illegal state (in which case the script will stop without producing 
output or changing its state). 

With the equivalence of the window structures we have that the target variable in the algorithm of 
script_f wd in both runs points to a window containing the same script in both runs. 

We can now distinguish between the possible values of S\ (b\).j. scriptstate.q = 
$2 (^ 2 ) j-scr ipt state, q: 

start In this case, a postMessage with exactly the same contents is sent to the same window. We therefore 
trivially have 7 -equivalence under ( 9,H ) on the states in this case. No output events are generated, 
and no nonces are used. Therefore, a-equivalence holds on the new states. 
expectTagKey In this case, for any change in the state to occur, a postMessage containing some term 
under the (dictionary) key tagKey sent from exactly the same window has to be in scriptinputs. From 
Condition 12(e)vi of Definition 79 we know that in scriptinputs either such a postMessage exists in 
both browsers or in none. 

23 This also applies when the browser challenged before, i.e., challenge in the browser’s state is _L. 
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As the tag contained in the postMessages is term-equivalent under proto-tags theta, we have that 
the RP domain inside the tag is either the same in both processing steps or dr i in h\ and dr 2 in bi- 
Additionally, eia (if contained in the URL parameters in the location of the script) is term-equivalent 
under proto-tags theta. It follows that the resulting postMessage, which contains eia, is either delivered 
to the receiver (which is either equal in both browsers or dr\ in b\ and dr 2 in /^o)- Additionally, no 
k € K can be contained in the eia, as it is taken from the document’s location. In any case, the resulting 
browser states are 7 -equivalent under ( 0,H). 

As no output events are produced, we have that E[ and E' 2 are /3-equivalent under ( 9,H,L ). As exactly 
the same number of nonces are chosen (in fact, no nonces are chosen), we have that the resulting 
configuration is a- equivalent. 

4. Si (b\).j. origin ^ {(dr\ , S), {dn, S), (fwddomain, S)}. 

Here, we assumte that the script in this case is the the attacker script R M , as it subsumes all other scripts. 
We first observe, that its “view”, i.e., the input terms it gets from the browser, is term-equivalent up to 
proto-tags 9 between (the scripts running in) Si (b\ ) and So (To). From the equivalence definition of states 
(Definition 79) we can see that: 

• The window tree has the same structure in both processing steps. All window terms are equal (up to 
their documents subterm). All same-origin documents contain only subterms that are term-equivalent 
up to 9 (again, up to their subwindows subterms). All non-same-origin documents become limited 
documents and therefore are equal (up to the subwindows, limited documents only contain the sub¬ 
windows and the document nonce). 

• The subterms cookies, localStorage, sessionStorage, scriptstate, and scriptinputs are 
term-equivalent up to 9. 

• The subterms ids and secrets are equal. 

• There is not k £ K as a subterm (except as keys for tags) in this view. We therefore have that no such 
term can be contained in the output command of the script, or in the new scriptstate. 

As the input of the script as a whole is term-equivalent up to 9, does not contain any placeholders in Vscript, 
and does not contain a key for any tag in 9, we have that the output of the script, i.e., scriptstate', cookies', 
localStorage', sessionStorage', command', must be term-equivalent up to proto-tags 9 (in particular, the 
same number of nonces is replaced in both output terms in both processing steps). Note that the first 
element of the command output must be equal between the two browsers (as it must be string) or otherwise 
the browsers will ignore the command in both processing steps. 

Analogously, we see that the input does not contain any subterm l £ L. 

We can now distinguish the possible commands the script can output (again, all parameters for these 
commands must be term-equivalent under 9): 

(a) Empty or invalid command: In this case, the browser outputs no message and its state is not changed, 
ct-equivalence is therefore trivially given. 

(b) (HREF, url,hrefwindow,noreferrer) : Here, the browser calls GETNAVIGABLEWINDOW to deter¬ 
mine the window in which the document will be loaded. Due to the synchronous window structure 
between the two browsers, the result will be the same in both processing steps (which may include 
creating a new window with a new nonce). 

Now, a new HTTP(S) request is assembled from the URL. A Referer header is added to the request 
from the document’s current location (which is term-equivalent under 9) and given to the SEND 
function. There, if the host part of the URL is CHALLENGE, it will be replaced by dr\ in b\ and by 
dr 2 in b 2 . (In this case, the o-equivalence in the following holds for //' := H U {«}, where n is the 
nonce of the generated HTTP request. Otherwise, it holds for H' := H.). Afterwards, for domains that 
are in the sts subterm of the browser’s state, the request will be rewritten to HTTPS. Any cookies for 
the domain in the requests are added. Note that both latter steps never apply to requests to dr\ or dr 2 
as per definition, there are no entries for these domains in sts and cookies.. The requests, which are 
^-equivalent under 9 are added to the pending DNS requests and fulfill Condition 12b of Definition 79. 
A DNS request is created in accordance with Condition lb or Condition la of Definition 80. The same 
number of nonce is chosen in both processing steps, and therefore o-equivalence holds. 

(c) (IFRAME, url, window) This case is completely parallel to Case 4b. 
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(d) (FORM, url,method , data,hrefwindow) This case is parallel to Case 4b, except that an Origin header is 
added. Its properties are the same as those of the Referer header in Case 4b. 

(e) (SETSCRIPT, window , script) In this case, the same document is manipulated in both processing steps 
in the same way. Note that only same-origin documents, i.e., attacker documents, can be manipulated. 
No output event is generated, and no nonces are chosen, a-equivalence is given trivially. 

(f) (SETSCRIPTSTATE, window,scriptstate) This case is parallel to Case 4e. 

(g) ( XHLWITPREQUEST, url,method, data,xlirreference) This case is parallel to Case 4b with the addition 
of the Origin header (see Case 4d) and the addition of a reference parameter, which is transferred into 
pendingDNS inside the browser (x hr reference). Therefore, for 7 -equivalence, it is important to note 
that this reference can only be a nonce (and therefore is equal in both processing steps). Otherwise, 
the browser stops in both processing steps. 

(h) (BACK ,window), (FORWARD, window), and (CLOSE, window) If the script outputs one of these com¬ 
mands, in both processing steps, the browsers will be manipulated in exactly the same way. No output 
events are generated, and no nonces are chosen. 

(i) (POSTMESSAGE, window, message, origin) In this case, a term containing message (term-equivalent 
under 9) is added to a document’s scriptinput term. If the origin is _L, the same term will be 
added to the same document in both processing steps. Otherwise, the term may only be added to 
one document (if, for example, the origin is (dr i,S) and the target documents in both browsers 
have the domain dr\ and dr 2 , respectively). In this case, however, the equivalence defined on the 
scriptinputs is preserved. This would only be possible for script_rp and only if the sender origin 
was (fwddomain,S). 

2 (navigate to URL): In this case, a new window is opened in the browser and a document is loaded from url. 

The states of both browsers are changed in the same way except if the domain of the URL is CHALLENGE. In 
both cases, a new (at this point empty) window is created and appended the windows subterm of the browsers. 
This subterm is therefore changed in exactly the same way. 

A new HTTP request is created and appended to pendingDNS. The generated requests in both processing steps 
can only differ in the host part iff the domain is CHALLENGE. In this case, in b\ the domain is replaced by dr\ 
and in £>2 by dr 2 and the a-equivalence in the following holds for //' := //{«}, where n is the nonce of the 
generated HTTP request. In both cases, the Condition 12b of Definition 79 is satisfied. 

The request cannot contain any / £ L or k £ K. 

The generated DNS requests are equivalent under Condition lb or Condition la of Definition 80. 

In both processing steps, three nonces are chosen. 

Therefore, we have a-equivalence for (S(,E(,N[) and (S^E^N^). 

3 (reload document): Here, an existing document is retrieved from its original location again. From the definition 

of 7 -equivalence under (9,H) we can see that whatever document is reloaded, its location is either (I) term- 
equivalent under 9, or (II) it is term-equivalent under 9 except for the domain, which is dr\ in b\ and dr 2 in 
bi- 

We note that in either case, the requests are constructed from the location and referrer properties of the 
document that is to be reloaded, and therefore, cannot contain any k £ K. 

In Case (I), we note that the domain cannot be CHALLENGE. If the document is reloaded, the same DNS request 
is issued in both browsers (therefore, /3-equivalence under ( 9,H,L ) is given), and an entry is added to the 
pending DNS messages such that we have 7 -equivalence under ( 9,H ). The same number of nonces is chosen 
in both runs, and we have a-equivalence. 

Case (II) is similar, but we have H' := H U {«}, where n is the nonce of the HTTP request that is added to the 
pending DNS entries. Then we have 7 -equivalence under (0,//'). Again, the same number of nonces is chosen 
and we have a-equivalence. 

Other Any other message is discarded by the browsers without any change to state or output events. 

Case p\ is some attacker: 

Here, only Case la from Definition 80 can apply to the input events, i.e., the input events are term-equivalent under 
proto-tags 9. This implies that the message was delivered to the same attacker process in both processing steps. Let A 
be that attacker process. With Case 10 of Definition 79 we have that S 1 (A) ^7 52 (A) and with Case 9 and Case 3 of 
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Definition 80 it follows immediately that the attacker cannot decrypt any of the tags in 9 in its knowledge. Further, in 
the attackers state there are no variables (from Vprocess)- 

With the output term being a fixed term (with variables) Tp roce ss £ T^({x} U Vprocess) and x being Si (A) or S2 (A), 
respectively, and there is no subterm l GL contained in either Si (A) or S 2 (A) (Condition 11 of Definition 79), it is easy 
to see that the output events are ^-equivalent under 9 , i.e., E^ t , there are not k € K contained in the output 

events (except as encryption keys for tags) and the used nonces are the same, i.e., N[ =N' 2 - The new state of the attacker 
in both processing steps consists of the input events, the output events, and the former state of the event, and, as such, 
is /3-equivalent under proto-tags 9. Therefore we have a-equivalence on the new configurations. 

□ 

This proves Theorem 3. ■ 
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